Administrivia

Ed to scribe 11/18

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Nov/0011.html

Minutes - FJH would like to make one change

<fjh> Group agrees to publish the Best Practices doc as first working draft

<fjh> propose changing resolution to read as "First Public Working Draft"

RESOLUTION: Minutes from 10/20 and 10/21 approved (with minor change as per fjh's comment)

fjh: Can we approve minutes of the 4th?

RESOLUTION: Minutes of 11/4 approved.

Best practices publication

fjh: one question: Do we want to publish the examples?
... need to make a decision today - is with examples OK?

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Nov/0012.html

smullan: May be difficult to remove them at this point, embedded in doc...

fjh: We don't want public publication of the examples.
... but members can have access. But can we agree on Hal's suggestion
... not make the files available to non-members

<brich> +1

fjh: Personal preference would be to publish

pdatta: Critical part of examples already in the doc.

<fjh> brad notes attacks are available for long time, so probably ok to publish

pdatta: but we need to be cautious

<fjh> hal notes if publish, cannot take it back

Hal: Don't see we loose by publishing.

<bhill> http://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_Handout.pdf

bhill: There are tools for these attacks too

fjh: Notes this is the first draft, not the final.

<bhill> https://www.isecpartners.com/samlpummel.html

fjh: Sounds like we're on the fence leaning to the cautious side

RESOLUTION: WG recommends not to publish the example files at this point

v1.1 roadmap

<fjh> http://www.w3.org/2008/xmlsec/Drafts/roadmap/roadmap.html

fjh: On ECC, only recommend, not MUST at this point, most likely

<shivaram> ECC NIST curves are free of IP as far as I know

<bal> I disagree with the suggestion that ECC only be RECOMMEND, not MUST

klanz: Does anyone know about IP problems with a MUST

fjh: Big item is to make sure 1.1. reflects our discussions so far.

<bal> Standard disclaimer: I'm not an IPR attorney. Having said that, it is my stong belief that MUST for the ECC NIST prime curves (P192, P256, P521) would not require implementers to take any IPR licenses.

<gedgar> is there any wording in NIST documents on IPR considerations for thier curves?

<shivaram> +q

<shivaram> may be get some clarification from Tim Polk @ NIST regarding ECC curves

Algorithms for v1.1

kyiu: Several problems found with xsd/DTD in RFCs
... and believes RFC 4050 defines EC point differently than X9.62
... Further issues e.g. with number of support digits.
... and some namespace scoping issues (DTD elements)
... (this is all in Kelvin's email)

<klanz> http://www.w3.org/2005/05/25-schema/SAP.html

<fjh> kelvin notes that converting to base 10 may be inefficient may be preferable to base64 encode, with respect to decimal type

<klanz> * Russian Doll,

<klanz> * Salami Slice,

<klanz> * Venetian Blind or

<klanz> * Garden of Eden

kyui: Working on proposal correcting this and in the ds namespace

<klanz> maybe there a similar techniques for DTD's ... Norm would know ;-)

kyui: also to cover interop with RFC 4050 through a profile

<klanz> I know G. Karlinger

<fjh> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg01125.html

<scribe> ACTION: kyiu to get in touch with RFC 4050 authors [recorded in http://www.w3.org/2008/11/11-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-105 - Get in touch with RFC 4050 authors [on Kelvin Yiu - due 2008-11-18].

<gedgar> Is this an issue, to reconcile RFC 4050 with X9.62 ?

magnus and klanz to help put Kelvin in touch with RFC 4050 authors

<esimon2> Is it possible to automatically generate the DTDs from the schemas (e.g. using XSLT)?

fjh: Let us focus on schema first and worry about the DTD later.

<gedgar> I agree that Schemas are the direction we are going here in Boeing.

Requirements

<gedgar> I should say that schemas are the direction we are going here in Boeing and it is more useful than DTDs

fjh: Certificates and DER encodings

<bal> +q

fjh: Maybe add attribute to indicate encoding?

<jwray> +q

scantor: Would like future version make encoding explicit
... do believe that most of non-DER/BER would not be handled. Then we can require DER/BER.

<fjh> scantor notes difficult to profile given complexity of protocol stack and involvement of CA etc

scantor: In terms of future work, combining DER/BER is a reasonable boundary.

bal: Would like to avoid this issue right now, refers to PKIX discussion. Implementations need to be flexible in what they receive/accept.

scantor: Something needs to understand the cert, right?

bal: Not really, because I pass it on.

scantor: Talking about the receiver...

bal: Even then you can ignore parts of it.
... Today's libraries are very flexible.

scantor: Not convinced of that - only BER/DER seen.
... My concern is to having to impement support for other codings

bal: Haven't seen this as an issue in practice.

jwray: Maybe draw the line between BER/DER and other encodings. Have only seen BER encoded, really.
... You have to touch DER in order to calculate the signature. DER is subset of BER.
... If requirement to support more than DER/BER then that needs to be clearly labeled.

klanz: Maybe a formal request to our working group. Should we inherit the PKIX problem?
... Canonicalization/encoding issue not just for us, it seems. And it must have been so for several years...

fjh: We can define reqs for XML signature going forward. E.g. to carry encoding information or to profile what formats are acceptable.
... Which is different from PKIX issues, IMO.

klanz: But are we the right place to solve it?

<fjh> magnus notes responsibility of signer and receiver, signer gets cert from CA, that might have incorrect encoding, but still usable

<fjh> magnus notes concern of introducing requirement on signer that might break existing implementations

<Zakim> fjh, you wanted to not 11 influence ca

fjh: Three questions: How to move forward?
... Is the sense that we should not put this in 1.1.
... from the sound of the discussion
... If we profile, will we influence CAs?

klanz: Whatever markup we add, it can only be a hint.

scantor: Don't believe this is PKIX responsibility and that is this group's responsibility.
... Going forward, should have a URI that represents the encoding.

<fjh> scantor notes, why not state that content is BER/DER encoded

scantor: Makes life easier for verifiers.

<fjh> smullan notes implementations often assume DER encoded, different issue that multiple encodings in a cert, eg extensions

smullan: We assume DER encoded. But may handle some parts that are incorrectly encoded. Open to put something in best practices.
... if a new format took off then nothing would work, most likely and an encoding tag would be required.

fjh: Scott has two proposals: URI encoding tag in 2.0 + profiling stating that BER/DER encoding.
... tentatively include and see what feedback we get?

klanz: Also a property on what encoding it was signed in?

<bal> i think it's clear that it has to be signed as DER

+1

<klanz> well, but many implementations verify raw

<klanz> as is

scantor: need to know the encoding in order to verify and make use of.

bal: If you only care about the public key then there are other ways...

scantor: Intend to get back to that too.

klanz: Be aware of the large deployed set of certs that should be used.

<fjh> suggest concrete proposal to recommend BER/DER with flexibility in extensions, also URI encoding tag

<magnus> Actually, extensions is not the only place that will need flexibility.

Derived data

<klanz> http://uddi.org/pubs/SchemaCentricCanonicalization-20050523.htm#sec-web-services-example

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0007.html

fjh: If not XSLT processing within the signature processing, could not we do that outside of the signature processing?
... Should this be a requirement in the doc?
... can we prevent arbitrary transforms?

klanz: Should be some openness to app developer, and use XSLT for this.
... Only specific transforms.

fjh: I have a concern, but will take this to list to reconcile.

<klanz> 2. Requirement: The ds:SignatureValue and the ds:SignedInfo shall be

<klanz> verified before the ds:Reference elements. Hence only signed

<klanz> ds:Transforms will be executed.

<klanz> Stylesheets referred to via xsl:include or xsl:import will have to be

<klanz> referred to by a ds:Reference previous to the ds:Reference in question

<klanz> (the one including/importing the other stylesheets).

Derived key types

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Aug/0064.html

<scribe> ACTION: magnus to work the text in the proposal to the req doc [recorded in http://www.w3.org/2008/11/11-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-106 - Work the text in the proposal to the req doc [on Magnus Nyström - due 2008-11-18].

magnus: Can this go in 1.next or would it have to wait for 2.0?

scantor: If it is a new type then maybe a separate document namespace that could be used with 1.1 and 2.0

fjh: Raises the question: If own namespace and separate doc or wait for 2.0?
... Maybe can be split off as separate piece of work and get it out earlier.

<scantor> it is an #other, so it has to be in a separate namespace to add it to the 1.x schema

<magnus> Yes, you're right, Scott.

Best practices

<fjh> Example file and empty XPath

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0005.html

fjh: Maybe leave for a while to get feedback from public review?

<fjh> konrad notes references on key lengths etc RSA-PSS paper

v.Next

<fjh> Profiling XPath for XML Schema

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0002.html

<fjh> XSL Streaming

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2008Nov/0010.html

fjh: Any volunteer to look at this?

<scribe> ACTION: pdatta to look at XSL streaming [recorded in http://www.w3.org/2008/11/11-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-107 - Look at XSL streaming [on Pratik Datta - due 2008-11-18].

<fjh> XPointer element scheme

<fjh> http://www.w3.org/TR/xptr-element/

klanz: Xpointer element scheme could be a simple yet rich way of selecting document subtrees

<scantor> +1

klanz: would not need transform chains at all.

scantor: Don't reject just because it maybe not can deal with all use cases...?

klanz: Maybe Xpointer element scheme could be required for 1.1?
... before inventing something why not use it?

<klanz> http://www.w3.org/TR/xptr-element/

<fjh> scantor notes qualified names may not be supported

fjh: Skip transform primitives for now.

<fjh> transform primitives

klanz: Maybe define simple set of transforms primitives?

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0000.html

fjh: If we don't canonicalize, do some of the concerns around WS go away?

klanz: Maybe some things should be part of transforms, like prefix rewriting.
... Advantages in large set of simple transforms, for app developers

<fjh> ck bal

fjh: Brian has question about level 0, 1 ... is this below the lowest level and other is for Konrad: What's next?

klanz: If we decide for 1.1. a need for WS normalization and backwards compat signatures then this could be useful.

<pdatta> whitespace removal and namespace prefix writing should be attributes of canonilicalization transform

fjh: Please comment on today's discussions items, especially 1.1 and roadmap.