<trackbot> Date: 18 November 2008

<scribe> Scribe: Ed Simon

<scribe> ScribeNick: esimon2

Administrative

<fjh> 25 November, 23 December, 30 December 2008 Teleconferences cancelled

<fjh> Next meeting 2 December, John Wray is scheduled to scribe, 9 Dec Konrad scheduled to scribe

Best Practices published and on W3C web site

<fjh> XML Signature Best Practices First Public Working Draft published

<fjh> See http://www.w3.org/News/2008#item187

Minutes

<fjh> http://www.w3.org/2008/11/11-xmlsec-minutes

<scribe> new ones are posted and in official place

RESOLUTION: Minutes are approved

That's the Nov. 11 minutes!

V 1.1

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

Certificate encoding

Issue is that one cannot parse the certificate, not its validation.

Will try to incorporate Magnus' suggestions.

<klanz2> Magnus: http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0041.html

Preceding comments from Scott

Magnus: Do we want normative language?
... will review Scott's proposal and seek to merge his and Scott's

<klanz2> RECOMMEND ... DER ... ?

Konrad: Suggest details of recommendations go into best practices not spec

Scott: That would be OK.

Frederic: Normative language should be in spec.

Scott: Implementation details in Best practices

Ed: Can't refer in spec to best practices because best practices is not normative

<scribe> ACTION: scantor to Provide Proposal re Consolidated Certificate Encoding Proposal [recorded in http://www.w3.org/2008/11/18-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-108 - Provide Proposal re Consolidated Certificate Encoding Proposal [on Scott Cantor - due 2008-11-25].

<fjh> include material for both rec and best practices as appropriate

Scott: Feedback welcome about inclusion into best practices

(Certificate Encoding: Aim is for 1.1, not 1.0 Errata)

<fjh> konrad asks whether change for cert encoding should be in 1.1 or errata to 2nd edition

<fjh> sense of group appears to be 1.1 but can defer until proposal

<klanz2> I was not able to open the links ...

<klanz2> Could we have the links first?

<klanz2> okay, the %20 ...

Algorithms

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

Magnus: Contacted Simon Blake-Wilson and is waiting to hear back from him.

Kelvin: change in definition of EC public key element

<kyiu> http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm

<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm

<fjh> see 4.4.2.3

Kelvin: instead or reusing 4050 definition, better to redesign it...

<fjh> 4.4.2.3 The ECKeyValue Element

<klanz2> http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/review.html

Konrad: use change highlighting

Frederic: Will do.

<kyiu> redefined ECDSAKeyValue to ECKeyValue and simplified the common case where curves are identified by OIDs

<kyiu> some subelements of ECKeyValues have been updated to align with the ASN.1 definition in ANSI X9.62 and RFC 3279

<klanz2> btw. Editorial ... please use IAIK instead of A-SIT for my affiliation ...

<kyiu> if you look at the example in 4.4.2.3

<fjh> <NamedCurve URN="urn:oid:1.2.840.10045.3.1.7" />

<kyiu> you end up with just the named curve and X Y coordinate

<kyiu> X and Y are encoded using a function defined in X9.62, then encode again using base 64

<kyiu> biggest deviation from 4050 is in how explicit curve parameters are represented

<klanz2> 4.4.2.3 : http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm#sec-ECKeyValue

<kyiu> in section 4.4.2.3.1

<fjh> 4.4.2.3.1 Explicit Curve Parameters

<klanz2> http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm#sec-ECParameters

<kyiu> instead of fixing 4050, I tried to realign with the ASN.1 definition in X9.62 and RFC 3279

Kelvin: Aim is to align with ASN.1 definition

<klanz2> is this publicly visible?

<kyiu> there were also differences in how 4050 expressed various fieldID types from X9.62

<fjh> 4.4.2.3.2 Compatibility with RFC 4050

<klanz2> http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm#sec-RFC4050Compat

Kelvin: Want implementations to also support 4050

<kyiu> section 4.4.2.3.2

<kyiu> recommend to support the old RFC 4050 definition of ECDSAKeyValue

Kelvin: Need to support only a subset of 4050.
... if you want to support all curve parameters, use the new definition.

<klanz2> http://www.w3.org/2000/09/xmldsig#ECKeyValue

Kelvin: New markup uses the new XML Dsig namespace

Konrad: Will need to see if that is possible.

<scribe> ...new markup should be in new namespace

fjh: 1.1 will not have a new namespace

Ed: Version element/attribute?

Konrad: Concern over aligning schemas and namespaces; some apps sign schemas

Frederic: New additions in new namespace

<klanz2> http://www.w3.org/2008/11/xmldsig#ECKeyValue

Kelvin: Done profile to deal with implementations not handling 4050.

<klanz2> could we add an include/import statement in an existing schema? or do we simply add normative language, that dsig implementations should be aware about this namespace

<kyiu> profile in section 4.4.2.3.2 was done to avoid some of the problems in the 4050 schema I outlined in my earlier email

Kelvin to update namespace as part of current action item.

<klanz2> klanz2: Maybe the RFC4050 Markup is supported anyway by reference, but I understand that you want to give special emphasis on the case explained in http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm#sec-RFC4050Compat ,

<klanz2> especially as there seems to be schema issues with digit length, correct?

Kelvin: Other parts needing work are in algorithm definitions

<fjh> 6.1 Algorithm Identifiers and Implementation Requirements

<klanz2> ... in the other cases

<kyiu> yes, and there were other problems with the 4050 schema as well

<kyiu> section 6.1 - I added new URIs for ECDSA and SHA2

<fjh> doc states - Recommended HMAC-SHA256

<fjh> brich: why isn't this required

Bruce: Why is HMAC-SHA1 not required

Kelvin: Is OK with changing it to required, no strong feelings either way

<fjh> issue: hmac-sha256 required in 1.1?

<trackbot> Created ISSUE-74 - Hmac-sha256 required in 1.1? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/74/edit .

Konrad: Suggest put note on list re problems with RFC 4050

Kelvin: will contact authors of 4050

<klanz2> A W3C WG Note on what the issues with RFC 4050 are ... to have more persistance on the documentation about the rationale behind the changes ...

<fjh> 6.2.3 SHA-384

<fjh> 6.2.4 SHA-512

<fjh> 6.4.1 DSA

Kelvin: Will generate diff and send it out.

<klanz2> bruce: typo in references 4051 twice

Frederic: Problem with links in 2nd Editon
... OK with editing 2nd Edition in HTML
... for 1.1, we need to decide whether to move to XML format or use HTML
... will have to make transition at some point.

<klanz2> http://www.w3.org/2008/xmlsec/Drafts/xmldsig/XML%20Signature%20Syntax%20and%20Processing%201.1%20draft.htm#sec-SHA-384

<klanz2> ... instead of sha-384

fjh: We should fix namespace

<klanz2> Draft November 12, 2008

<klanz2> thanks kelvin

Derived Key

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

Magnus: Put in proposal, no new technical content, modification of what was in earlier wrt use case...
... considering requirements, and design options.

fjh: We should just add to requirements document and handle it there.

RESOLUTION: Add Magnus' work to requirements document

<scribe> ACTION: fjh to Add Magnus' work to Requirements Document [recorded in http://www.w3.org/2008/11/18-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-109 - Add Magnus' work to Requirements Document [on Frederick Hirsch - due 2008-11-25].

Schema Defaults

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

Magnus: Include in Best Practices wording on use of Schema default values

fjh: Is there a requirement, like in Canonicalization, to use or not use defaults?

Magnus: Not sure.

<klanz2> http://uddi.org/pubs/SchemaCentricCanonicalization-20050523.htm#sec-Limitations-of-existing

Klanz: Schema canonicalization does consider the issue of schema defaults

Konrad: Use Schema Canonicalization as resource for this issue.

ISSUE: Role of schema canonicalizaton wrt schema defaults

Magnus: Should there be text in best practices

Konrad: OK with discussing issue in Best Practices

<fjh> invite trackbot

<fjh> trackbot-ng

<scribe> ACTION: magnus to Draft Proposal re Schema Defaults and Best Practices [recorded in http://www.w3.org/2008/11/18-xmlsec-minutes.html#action03]

<fjh> ISSUE: Role of schema canonicalizaton wrt schema defaults

<trackbot> Created ISSUE-75 - Role of schema canonicalizaton wrt schema defaults ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/75/edit .

<klanz2> ACTION: magnus to Draft Proposal re Schema Defaults and Best Practices [recorded in http://www.w3.org/2008/11/18-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-110 - Draft Proposal re Schema Defaults and Best Practices [on Magnus Nyström - due 2008-11-25].

Backwards Compatibility

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

Frederic: Konrad had message that backwards compatibility could be achieved through transformation

<fjh> URI ="#xmlns(ds=http://www.w3.org/2000/09/xmldsig#)xpointer(here()/ancestor::ds:Reference/ds:Transforms[1]/ds:Transform[1]/InlineXML[1]/child::node()[not(self::text())])"

Konrad is reviewing whether we need to do any further work on this item.

Web Site

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

Shivaram: New web site draft package available; links to minutes missing, other minor stuff; readiy in couple of days

Frederic: Please send any comments to Shivaram.
... Thomas had two actions to add comments and test cases.

<klanz2> re Backwards Compatibility: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Jul/0001.html

Shivaram will wait to weekend before finalizing web site

<fjh> shivaram will run through html and link checker

Konrad: Proposal was to supply a hint to put data in correct order for streaming
... Get feedback from implementers
... Are there use cases for using current signatures in streaming

<klanz2> InlineXML

<fjh> konrad notes that this proposal outlines how to achieve streaming using Second Edition, could also be applicable to 1.1

Frederic: What do we next with this?

Konrad: Proposes "SupplyData" transform to realize this functionality.

<klanz2> A supply data transform ... with existing markup

Frederic: Get feedback from WG whether there should be a requirement in either 1.1 or 2.0 for this.
... In 2.0, there may be other ways of handiing this.

<fjh> is there a requirement for algorithm,data, digest/signature value order in 1.1?

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

<trackbot> Created ISSUE-76 - Http://lists.w3.org/Archives/Member/member-xmlsec/2008Nov/0029.html ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/76/edit .

<fjh> issue: is there a requirement for algorithm,data, digest/signature value order in 1.1?

<trackbot> Created ISSUE-77 - Is there a requirement for algorithm,data, digest/signature value order in 1.1? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/77/edit .

<fjh> issue 76 close

Namespace Undeclaration

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

Frederic: Konrad mentioned we need namespace undeclaration functionality for various purposes

Konrad: No matter what content you sign, you inherit the outer context. Outer context may be lost as data travels
... affected by removal of namespace nodes; is a general XML issue, not just ours.
... We need to handle XML ambiguities; may have security considerations if one does not handle them.

Konrad: Base 64 encoding of inline XML is opaque; when de-encoded, ambiguities may arise.
...example: Does removal of a node set affect the namespace declaration?

Frederic: Got feedback from XML Co-ordination WG that XML 1.1 issues were not going into XML 1.0
... Let's leave this for now and deal with it if needed when processing proposals:

<fjh> scantor notes that even with namespace undeclaration still need to deal with context situations

<klanz2> xml:insulate ..

Action Items Review

<klanz2> There is a need for things like EnvelopingSignatures, or Transport Protocols like DSS/DSS-X that carry pay load ...

Action-55: close

<trackbot> ACTION-55 Check with WS-Federation regarding XML Signature 2nd edition references notes added

ACTION-55 Close

<klanz2> this payload should be preferably context free ... i.e. no namespace declarations, xml:lang, xml:space (etc ... ) should not be inherited by the payload, ...

Frederic to close impending actions

Reviewing open actions...

<klanz2> true opaqueness is at the moment achieved by base64 encoding only, which prevents one form parsing the contents in the same step ... and increases the size ...

Frederic: Associate Action-13 with...

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

<fjh> and with soap streaming from maint wg

ACTION-13 Close

<fjh> then close 13

Action 88 to be closed end of year

<klanz2> so the take away from Namespace Undeclaration, may be that an attribute like dsig11:insulate="*" to lose all context (esentially a new parser should be spawned), if finer granularity would be required things like dsig11:insulate="xmlns xmlns:* xml:lang xml:base" ... etc ... in a very simple spec just like xml:id could be a useful thing ... but I think the whole issue needs some more thought ...

WG will produce W3C Note for algorithms associated with XML security indicating where they are defined.

RESOLUTION: WG will produce W3C Note for algorithms associated with XML security indicating where they are defined.

Konrad: Maintain old DS references for legacy purposes.

Kelvin will highlight issues he found wrt algorithms.

scribe: will send out email this week.

Action-106 close

<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008May/0026.html

(above link associated with Action-13)

<klanz2> Re streaming web services (ACTION-13): http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2008May/0004.html