XML Security Working Group Teleconference
17 March 2009

Administrative

<trackbot> Date: 17 March 2009

<fjh> trackbot-ng, start telcon

<trackbot> Meeting: XML Security Working Group Teleconference

<trackbot> Date: 17 March 2009

<fjh> Scribe: Magnus Nyström

<hal> I can't scribe on March 31

<tlr> ACTION: thomas to prepare registration questionnaire for face-to-face [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-230 - Prepare registration questionnaire for face-to-face [on Thomas Roessler - due 2009-03-24].

<fjh> Scribing plan has 24 March Scott, 31 is Ed , Hal 7 april

<fjh> logistics for f2f

<fjh> http://lists.w3.org/Archives/Member/member-xmlsec/2009Mar/0015.html

fjh: suggestion to cancel 5/19 and 5/26

RESOLUTION: Cancel meetings 5/19 and 5/26

Minutes approval

fjh: Can we approve minutes from March 10?

<fjh> http://www.w3.org/2009/03/10-xmlsec-minutes.html

RESOLUTION: Minutes from 3/10 approved.

Editorial updates

<fjh> Best Practices

<fjh> Change text to 2.7 as agreed on last call

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0020.htm

<fjh> Signature Properties

<fjh> Update Created property, add editorial section on RFC2119, RFC2119

<fjh> reference, update RFC2119 term formatting.

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0024.htm

<fjh> Please review identifier and created properties:

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html#identifier-property

<fjh> Derived Keys

<fjh> Updated RFC 2119 term formatting

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0024.html

<fjh> XML Encryption

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0036.html

<fjh> padding updated

<fjh> Widget Signature

<fjh> http://dev.w3.org/2006/waf/widgets-digsig/

1.1. Interop planning

fjh: Sean, can you start to draft test cases?

sean: Within the next few weeks ...
... will drop some test vectors and people can comment if they cover enough

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0019.html

fjh: Thanks, encourages participation in this work.

Higher-level ECC curves in 1.1

fjh: Believe this is still open...?
... so is ongoing.

Curves in XML Encryption 1.1

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0035.html

bal: Action was to specify mandated and recommended curves for XML Encryption (ECDH)
... drafted 2nd paragraph to identify these curves.

<bal> ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in section 5.7.1.2 of NIST SP 800-56A [SP800-56A]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters.

<bal> Compliant implementations are REQUIRED to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS186-3]. (This is the same curve that is REQUIRED in XMLDSIG 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It is further RECOMMENDED that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively.

magnus: Last sentence could also be used in XMLDsig to cover Kelvin's action.

fjh: Makes sense to incorporate Brian's suggested text in the document

RESOLUTION: Add Brian's proposal for ACTION-229 to XML Encryption 1.1

<fjh> action bal to update XML Encryption 1.1 for ACTION-227 proposal

<trackbot> Created ACTION-231 - Update XML Encryption 1.1 for ACTION-227 proposal [on Brian LaMacchia - due 2009-03-24].

RESOLUTION: Add final sentence of Brian's proposal to XML DSig 1.1 (closes Action-225)

EC Point type

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0033.html

fjh: Better to have required attribute than default in my opinion

<scantor> +1

fjh: Should the hash algorithm be required?

magnus: Probably best, not onerous for sender

fjh: Additional text covering semantics is required.

RESOLUTION: Adopt proposal on curve validation including requiring hash algorithm attribute to be present

<scribe> ACTION: magnus to update XML Dsig document for schema and semantics for curve validation [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-232 - Update XML Dsig document for schema and semantics for curve validation [on Magnus Nyström - due 2009-03-24].

<scribe> ACTION: magnus to propose text covering semantics for curve validation [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-233 - Propose text covering semantics for curve validation [on Magnus Nyström - due 2009-03-24].

fjh: We will also need to check the schema for this at some point...

Exclusive canonicalization - mandatory algorithm

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0008.html

fjh: Suggest to make it mandatory algorithm...

bal: Notes the downside of more mandatory algorithms
... what implications for v2? Only exclusive C14n?

fjh: Unknown at this point, many dependencies

bal: Two reasons for: Needed in number of protocols, and you anyway (more or less) have it with inclusive

hal: Actually meant other way around, with exclusive C14N you more or less have inclusive also.

<fjh> bal noted, needed to do higher level protocols, ws* and saml, and pretty much have inclusive if exclusive is implemented

fjh: Choice - do nothing or go ahead and make exclusive mandatory

RESOLUTION: Exclusive c14n to be mandatory algorithm in XMLDsig 1.1.

<scribe> ACTION: fjh to update XMLDsig with mandating exclusive c14n [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-234 - Update XMLDsig with mandating exclusive c14n [on Frederick Hirsch - due 2009-03-24].

ECC keys in key info

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0028.html

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0030.html

scantor: No need for explicit keys here, since subjectkeyinfo contains algorithm

<scantor> FtF outcome was to define a top level child element to carry ASN.1 encoded SubjectPublicKeyInfo

scantor: Assumed the keyvaluetype already covered ECC

<scribe> ACTION: scantor to propose to the list new proposal on including ASN.1 encoded SubjPubKeyInfo [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action05]

<fjh> RFC 5480 Elliptic Curve Cryptography Subject Public Key Information

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0021.html

<fjh> magnus notes need to add ecc value type, already have consensus

<scribe> ACTION: magnus to add ECKey value as child of KeyValueType [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action07]

<trackbot> Created ACTION-236 - Add ECKey value as child of KeyValueType [on Magnus Nyström - due 2009-03-24].

<scantor> can't speak to correctness, but ECKeyValue is already in the FPWD alongside DSA and RSA

<fjh> magnus notes that this RFC 5480 was used to generate proposals within this wg

<fjh> scott notes we need to check text and stand alone document

<fjh> scott as part of action-236

<fjh> draft documents

<fjh> http://www.w3.org/2008/xmlsec/wiki/PublicationStatus

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-KeyValue

<fjh> magnus notes that schema snippet is missing in 4.4.2

<fjh> scott asks whether we can leave in any and also have new element with different namespace

<fjh> scott notes we need to make sure schema will work properly, given wildcard

<fjh> scott notes issue is multiple namespaces

<fjh> scott notes cannot add explicitly as a choice

<fjh> scott notes, may need to test the schema and test the instance through various parsers, testing for ambiguity

<fjh> magnus notes he will try, otherwise will add as comment

scantor: If 2.0 is in new namespace then we can add it

tlr: Cannot extend here, will cause ambiguity

magnus: Will investigate, and add as comment if not possible.

C14N vNext

<fjh> additional requirements

<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Mar/0034.html

pdatta: Proposing XML stream reader - XML presented as elements
... Would like canonicalizer to work with this event stream
... event stream simplifies, and is ordered by definition (unlike a node set)
... canonicalizer canonicalizes a few nodes from input stream and repeats in a chunk-like fashion
... Output will as usual be a byte stream

fjh: Canonicalizer should be able to work on chunks

pdatta: Must disallow attributes without owners

fjh: Requiring XML stream is a low-level requirement - do we want such requirements?

csolc: Can the input be abstracted - node set in DOM or something else?

fjh: Theme is to get away from node sets and DOM - we have one suggestion on how to do this here...

pdatta: Multiple options for input to canonicalizer: subtrees, event stream (but tied to stream parser), ...

<fjh> editors draft of transform simplification

<fjh> http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#design

pdatta: Section 4.4 discusses the c14n element
... not a standalone transform by itself

<fjh> pratik notes combining canonicalization and digesting could be more efficient, not having to store intermediate representation

pdatta: Proposal considers ways discussed at the f2f. Attributes to indicate c14n mode (like exclusive)

<fjh> pratik notes to avoid difficulty with knowing whitespace semantics, have parameter to signal trimming whitespace

pdatta: Another parameter is serialization ...
... e.g. to make use of EXI

pdatta: Fifth point: Preserved prefixes

<fjh> pratik notes a number of choices re serializations

<fjh> pratik notes deal with QName in content by making prefix non-significant via various approaches, full URI or unique prefix for each

pdatta: Some issues around DTD validation and entity expansion

bhill:Many issues with DTD, when to expand, remote DTDs etc

pdatta: Overall, a single algorithm with multiple params meaning it can do different things

scantor: What are the trade-offs of varying the inputs - could you constrain the inputs for people to use that and same time have algorithms model?

pdatta: Could be useful with new c14n algorithm...

scantor: Not against proposal, just looking at alternatives in case there is concern.

<fjh> scott notes question 4.5 indicates how to do extensions, might be an issue

pdatta: In section 4.5, tries to list transforms related to c14n...

scantor: Why not just change the transform -if we need to add attributes etc. it seems open-ended?

<fjh> maybe we need an extension point for adding declarative statements

<fjh> especially for other communities, e.g. WS* etc

pdatta: STR transform is in effect split in two parts

scantor: Attributes will in effect be critical extensions since you must fail if you don't know the semantics of them
... not to different from transforms today.

<fjh> scott asks whether attribute wildcarding is the best way to go?

klanz2: Not too worried, because if you don't understand, signature won't validate.

hal: False negatives arent as seriously, but still of a concern because may undermine confidence

fjh: We're discussing whether or not declarative attributes are essential/critical or not...?

klanz2:If not understood, ignore it, the XML approach. Can tell from digest if there is an issue, so ok
... - have warnings of what might have caused failure

scantor:Attributes cannot have parameter etc
...One problem with attributes as extension points is that they do not allow parameterization of extensions - but maybe we can embed elements as well.

tlr: Would like to split discussion between the classes of extensions and then the markup.
... suggest to stay on the design level at the moment.

fjh: Not sure extensions need to be part of the schema, concerned about having to change the schema to do extensions.

<klanz2> Does fjh ask for a set type of attributes as modeled by attributes ... ?

<klanz2> xs:anyAttribute vs. xs:any?

<scantor> yeah

<klanz2> what about an optional extension parameters element child with arbitrary attributes?

<scantor> my suggestion was if we're supportive of this proposal, let's take it forward in earnest

<fjh> note that property list could be used for extensions, as alternative to extending schema

<klanz2> Proposal0: no extensions at all factor into the transform ...

<klanz2> Proposal1: ExtensionAttributes peer with other attributes 1.1 in no namespace 1.2 in the same namespace 1.3 in a different namespace ...

<klanz2> Proposal2: model in a seperate element as container for arbitrary attributes

<klanz2> maybe good principles for Extensions are either 1. do not allow for extension 2. if there is really a need for extensions needed let them be easily be recognizeable as such 3. Design the extensions so that they can be easily ignored without danger for security

<klanz2> ... 4. maybe issue warnings for ignored extensions 5. avoid critical extensions where possible

fjh: General agreement on the transform simplification; needs to be detailed further

<fjh> konrad child as parameter to have set of parameters, set of extension attributes

klanz2: Suggesting element to capture extension attributes

pdatta: Not sure if we have consensus...?

fjh: Need a little more time for feedback; suggest to use mailing list to flush out thoughts on the proposal
... especially to work out the extensions issue - proposal to use the list for this.

scantor: Need to get consensus if we should rearchitecture the model around something like this proposal and understand what possibly will be lost
... if there is consensus then concrete markup needs to be done.

fjh: Generally in favor of this approach...anyone that disagrees or needs more time?

tlr: Discussion needs to be structured. Undecided at this point on this approach.

fjh: High-level is declarative approach driven by attributes. May not need details for that.

scantor:Why is transform section there

fjh: Need to hash this out on the list
... We are asking for concrete proposals and thoughts on the list.

tlr: Maybe Scott can highlight differences between the two proposals?

fjh: If you can also frame the questions we need to answer, Scott?

scantor: On high-level, we do not have a proposal for how to handle extensions, but may be possible to handle later
... not critical to basic acceptance of design.

<scribe> ACTION: scantor to highlight critical issues around the proposed c14n simplifications - maybe frame as questions for group to think about. [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action08]

<trackbot> Created ACTION-237 - Highlight critical issues around the proposed c14n simplifications - maybe frame as questions for group to think about. [on Scott Cantor - due 2009-03-24].

Pending Actions

<tlr> action-222?

<trackbot> ACTION-222 -- Konrad Lanz to make proposal RIPE algorithms -- due 2009-03-03 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2008/xmlsec/track/actions/222

tlr: Could accept as optional; but need references and do not need example

<scribe> ACTION: klanz2 to update the proposal associated with ACTION-222 and send to list. [recorded in http://www.w3.org/2009/03/17-xmlsec-minutes.html#action09]

<trackbot> Created ACTION-238 - Update the proposal associated with ACTION-222 and send to list. [on Konrad Lanz - due 2009-03-24].