See also: IRC log
<trackbot> Date: 18 November 2008
<scribe> Scribe: Ed Simon
<scribe> ScribeNick: esimon2
<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
<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!
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Nov/0037.html
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 ...
<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
<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
<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
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> ... instead of sha-384
fjh: We should fix namespace
<klanz2> Draft November 12, 2008
<klanz2> thanks kelvin
<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].
<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].
<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.
<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
<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 ..
<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