See also: IRC log
RESOLUTION: minutes from 6 January 2009 approved
XML signature 1.1, there is a new draft
XML encryption 1.1, there is a new draft
updates signature algs
updated signature properties
people should look at latest
<klanz2> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm
[Going through redline version]
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview_diff.htm
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview_diff.htm
<shivaram> Attendees here at F2F: Frederick, Rob Miller, Pratik Datta, Sean Mullan, Shivaram Mysore, Phil Hallam-Baker, Kelvin Yiu, Brian LaMacchia. Gerald
hlochart: Kelvin, should add self as an editor
<klanz2> > This document is also available in these non-normative formats: XHTML with color-coded revision indicators
<klanz2> The link to the colored version is broken
kelvin: have addes ecdsa
<fjh> ecdsa required now, rsa now required in section 4.4.2
kelvin: look at the schema, note that have not put the element as a value under keyinfo
hlockhart: need to make a decision on dtds, should we drop them now or later
thomas: can make decision as a group.
kelvin: need an auxilliary schema for additions
<tlr> ISSUE: ECDSA
<trackbot> Created ISSUE-80 - ECDSA ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/80/edit .
?? not determing the strength of the algorithm just explaining how to use it
bal: we say something about DSA
<tlr> requires new elements; what do we do about schema and DTD?
<trackbot> Created ISSUE-81 - ECDSA requires new elements; what do we do about schema and DTD? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/81/edit .
bal: because the mandatory to
implement are for ECDSA at least the ??curve, the strenght of
the algorithm is implied
... do not have a 2048 bit RSA identifier
<fjh> question - is ecdsa available via openssl?
gerald: life of the airframe plus 50 years!!
bal: have a key size, NIST makes
a recomendation out to 2030
... on the ecc side have recommendations for particular
curves
... can make a recommendation for 2048 bit
<fjh> phb: useful to note NIST recommendations re key length, include those recommendations, also RSA recommendations
<klanz2> http://www.keylength.com/
<fjh> phb: if go beyond 2048 may not get security corresponding to length
<fjh> bal: are 1.1 conformant implementations required to support a minimum key length?
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview_diff.htm
bal: should the spec mandate support for a particular range of RSA key sizes?
<fjh> issue: should 1.1 spec mandate support for range of RSA key sizes?
<trackbot> Created ISSUE-82 - Should 1.1 spec mandate support for range of RSA key sizes? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/82/edit .
<fjh> bal: minimum bar of 2048
<klanz2> Good overview: http://www.keylength.com/en/3/
<esimon2> Ed is listen-only; will need to be stepping in and out frequently.
PHB what we specify here is a minmum key size implementations must support which is defacto the largest you can depend upon
BAL happy to draft out similar text to DSA for RSA but need to know what to do
<fjh> section 4.4.23. ECKeyValue
<klanz2> I can send it to people at our Institute ...
hal: who is in a position to review this, what experts do we have in ECC?
Bal: have reviewed it but..
Thomas: can we change the URI parameter to URI, not URN!
<fjh> ie URI= instead of URN=
<scribe> ACTION: Kelvin to change URN= to URI= [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-137 - Change URN= to URI= [on Kelvin Yiu - due 2009-01-20].
Kelvin: another way to check this section is to compare against RFC 3279
<scribe> ACTION: PHB to compare 4.4.2.3 to RFC 3279 to determine if they are consistent [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-138 - Compare 4.4.2.3 to RFC 3279 to determine if they are consistent [on Phillip Hallam-Baker - due 2009-01-20].
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview_diff.htm
Kelvin: have changed way we
specify a point, using cryptobinary rather than big integers,
...
... performance issues converting to base 10
<shivaram> <complexType name="NameCurveType">
<shivaram> must be "NamedCurveType"
<scribe> ACTION: Kelvin <complexType name="NameCurveType" must be "NamedCurveType" [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-139 - <complexType name=\"NameCurveType\" must be \"NamedCurveType\" [on Kelvin Yiu - due 2009-01-20].
kyiu: Section 4.2.3.1 - again
just a conversion from RFC 3279...
... compatibility with RFC 4050 means that the attribute MUST
be called URN= and so earlier action 137 shoukld be cancelled
and replace with an explanation of why it is this way
<fjh> close ACTION-137
<trackbot> ACTION-137 Change URN= to URI= closed
<klanz2> As we are discussing Algorithms, what happened to the RFC 4051 drafts by Donald Eastlake, did they expire?
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2008Mar/0002.html
bal: section 6.1 - have restructured this to make clearer
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0032.html
<klanz2> Does anyone know who is taking care of RFC 4051 at the moment?
PHB: issue, text says that there is only one digest, we have four
<fjh> see the algorithms draft...
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/0010.html
<klanz2> It seems identifiers requested there seem to go missing?
<scribe> ACTION: kyiu change text in 6.2 to remove statement that there is only one digest [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-140 - Change text in 6.2 to remove statement that there is only one digest [on Kelvin Yiu - due 2009-01-20].
<fjh> 6.2.2
shivaram: we have a reference to XML encryption here, is that acceptabe?
BAL: yes, it is just the namespace for the algorithm
<klanz2> It seems that ecdsa-ripemd160 and ecdsa-whirlpool have not made it into a new version of RFC 4051 ... could we file an ISSUE for this ?
<scribe> ACTION: kyiu change URI in 6.2.3 to be SHA-384 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-141 - Change URI in 6.2.3 to be SHA-384 [on Kelvin Yiu - due 2009-01-20].
BAL:Section 6.4.1 -don't know
when the FIPS will come out, but will probably not change it
much
... when it comes out do we change the algs to the new algs and
key sizes and will any be recommended.
... Don't see anyone talking about longer DSA with longer key
sizes
various: May not be good idea but good to have there
BAL: should have placeholders for the FIPS definitions of DSA and decide whether to put them in this doc as optional
<scribe> ACTION: bal to come up with identifiers and add to the algs doc for the new DSA algorithms [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-142 - Come up with identifiers and add to the algs doc for the new DSA algorithms [on Brian LaMacchia - due 2009-01-20].
<bal> to clarify, placeholders for the forthcoming FIPS 186-3 DSAwithSHA256, DSAwithSHA384, DSAwithSHA521
klanz: The new algorithms play important roles as being the same length for smartcard use etc.
<fjh> issue ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051?
<fjh> issue: ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051?
<trackbot> Created ISSUE-83 - Ecdsa-ripemd160 and ecdsa-whirlpool need identifiers, rfc4051? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/83/edit .
klanz: issue is identifier seems to already be allocated, question is whether we can add as optional identifiers
<bal> RFC 4051 is a published RFC
tlr: RFC4051 is public... Don was
asking for new namespace for a successor draft which has two
algs added to it and expired.
... should we consider our work as a successor...
<fjh> this wg is on path to considering its Algorithms draft as a successor to 4051
<fjh> need to check with Don
tlr: in which case we should be adding algoirthm uris of that type in this
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Nov/0010.html
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Oct/0032.html
<klanz2> +1 tlr if I correctly understood him ... W3C Note which is well documenting our best knowlege of specified URIs and commonly used ones ....
<general discussion of how to handle this issue in the large for unbounded identifiers>
<klanz2> @phil and tlr: backtrack the IANA discussions http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2008Apr/0004.html
<Gerald-Edgar> I am having people review the ECC material and I will respond
Section 6.4.2
klanz: asks for algorithms to be defined
tlr: can you put the ids in the chat
<fjh> konrad notes 4051 bis expired
<fjh> brich ok with note identifying algorithms
bruce: comments on this, existence of a note that identifies uris for an algorithm is ok. Idea that we might specify ones that are optional or required
hal: normative is not the intent
<fjh> section 6.4.2 updated section title add sha algorithms
kyiu: update to the section, added identifiers with the SHA-xx algs
<klanz2> klanz: I'd like to see ecdsa-ripemd160 and ecdsa-whirlpool in our Algorithms Note
section 6.4.3
kyiu: new section, text describing how to format the ECDSA alg is new
<klanz2> do we have a link to the Algo note?
kyiu: is it ok to reference non free documentation
<fjh> ansi x9
bal: its a common problem, everyone references the ECC stuff but you have to shell out $100 for it
<fjh> normative or informative reference?
<fjh> issue is i2os definition
kyiu: can summarize the relevant chunk
<scribe> ACTION: kyiu to summarize the i2os function and put it in the doc [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-143 - Summarize the i2os function and put it in the doc [on Kelvin Yiu - due 2009-01-20].
<kyiu> I will look for a public document that contains the field to octet string conversion function to reference
tlr: would like to do this before
we go to working draft
... is this the same function we already use in 4.0.1?
... we use integer to octet string conversion from IEEE
1463
bal: not free either!
<kyiu> If I cannot find a public and free reference, then I will paraphrase the description in X9.62
tlr: is what 4.0.1 says sufficient? if so are done.
hal: may have a more general document chaining issue...
Pratik: do we have the relevant X.509 support?
kyiu: its all supportable in X.509v3
<fjh> kyiu notes ECC noted in this document material should be
PHB: OK so long as what we do fits with PKIX
BAL: I think we are good, using
same sets of curve
... question is are we mandating that DSIG platforms support
X.509 EC certs
... as a practical matter, going to have to support ECC
anyway.
fjh: general point that they
should be compatible
... can make proposal to list if would like
kyiu: found similar function in section G will change reference
<kyiu> the same function is also defined in SECG (section 2.3.5)
<kyiu> I will change the reference from X9.62 to SECG
<scribe> ACTION: kyiu drop the addresses section [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-144 - Drop the addresses section [on Kelvin Yiu - due 2009-01-20].
tlr: would like to go back to 4050 compatibility bit
<fjh> section 4.4.2.3.2
kyiu: recommending the two track
approach because there are existing libraries that it is useful
to be able to interop with.
... is issue optional or recommended.
hal: cannot say MUST do A but SHOULD do B
tlr: yes we are proposing two
mutually incompatible formats here
... if 4050 merits changing the format, then merits
incompatibility
... when would you use this profile
bal: only if interoperating with something
tlr: "if you want to use 4050 then should use this profile"
<fjh> may instead of should?
bal: what we are trying to say nicely is 4050 got it wrong, here is how to do it right if you have to.
<fjh> if you need to interoperate with 4050 implementations then may do this.
kyiu: can make it conditional, if you want interop then do this...
tlr: wondering if better to put this in best practices
<klanz2> +1 to strive interop with RFC 4050
fjh: think it should be in spec, not best practices, soften language but keep it there
<scribe> ACTION: kyiu to change language to 4,4.2.3.2 to say if you need to interoperate with 4050 implementations then may do this. [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-145 - Change language to 4,4.2.3.2 to say if you need to interoperate with 4050 implementations then may do this. [on Kelvin Yiu - due 2009-01-20].
fjh: finished with signature for now
<klanz2> btw @the algo note editors the expired Easlake drafts for the RFC4051 replacement can be found here http://tools.ietf.org/html/draft-eastlake-additional-xmlsec-uris-00#section-2.3.6 may be associate this with the issue surrounding http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160
<fjh> pratik: RFC 3279 missing
<scribe> ACTION: kyiu add rfc 3279 to references [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action10]
<trackbot> Created ACTION-146 - Add rfc 3279 to references [on Kelvin Yiu - due 2009-01-20].
<fjh> section 4.0 has reference to ECDSAKeyValue in DTD...
<scribe> ACTION: kyiu dtd isremove ref to ECDSAKeyValue in dtd in 4.0 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-147 - Dtd isremove ref to ECDSAKeyValue in dtd in 4.0 [on Kelvin Yiu - due 2009-01-20].
<fjh> hal noted RFC 2119 keywords should be capitalized.
hal: note if you are using 2019 keywords these SHOULD be capitalized
??: The DTD mention of ECDSAKeyValue is from the initial version if XML Signature, and explains possible uses of an extension point. Don't remove.
<scribe>close ACTION-147
<trackbot> ACTION-147 Dtd remove ref to ECDSAKeyValue in dtd in 4.0 closed
<shivaram> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview_diff.htm
Section 5.5.3
kyiu Has a reference to signature, so must publish these together
Section 5.5.4 done this way for compatibility with S/MIME where this is how it is done
kyiu: referenced the key derrivation function from SP80056A
BAL: think we have the simplest set to do this with minimal frilly options
<scribe> ACTION: kyiu: close the conplex type element in 5.5.4 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-148 - Close the conplex type element in 5.5.4 [on Kelvin Yiu - due 2009-01-20].
<kyiu> change reference to X9.63 in XmlEnc to SECG
<scribe> ACTION: kyiu change reference X.9.63 to section G [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action13]
<trackbot> Created ACTION-149 - Change reference X.9.63 to section G [on Kelvin Yiu - due 2009-01-20].
fjh: timing issues, would like to get this out as soon as possible,
smullan: would like to check on Java dependencies
<scribe> ACTION: smullan to check Java API dependencies/compatibility [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action14]
<trackbot> Created ACTION-150 - Check Java API dependencies/compatibility [on Sean Mullan - due 2009-01-20].
<klanz2> @tlr: is that enough information to put ecdsa-ripemd160 and *-whirlpool identifiers ...
<klanz2> http://www.w3.org/2008/xmlsec/track/issues/83
<klanz2> into the algorithm note
<klanz2> ?
<klanz2> I'll be gone for five more minutes ...
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0026.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0024.html
tlr: text does allow for change to doc without changing namespace but can make this more clear by dropping the sentence that suggests there will be a change
fjh: what about the additional schemas and namespaces for the ecc stuff?
tlr: probably worth calling out the new identifiers in section 1.3 as well
<scribe> ACTION: tlr to propose changes [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action15]
<trackbot> Created ACTION-151 - Propose changes [on Thomas Roessler - due 2009-01-20].
fjh: any objection to accepting the changes as proposed
RESOLUTION: accept tlr's proposal
<scribe> ACTION: bal to implement versioning change in sig and encryption 1.1 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action16]
<trackbot> Created ACTION-152 - Implement versioning change in sig and encryption 1.1 [on Brian LaMacchia - due 2009-01-20].
<tlr> ACTION-151: "changes" refer to smoothing text about namespace URIs
<trackbot> ACTION-151 Propose changes notes added
tlr: going back to the ECC piece, how to not change the schema
<csolc> or can we define a hint
<csolc> like a PI
<csolc> so that processors can look for that markup to see if the signature is 1.1
fjh: if we need to update schema for 1.1
tlr: might want to figure out way to use uniform schema
<fjh> tlr: if we use an extension point can we instead define in core schema without a versioning issue?
<fjh> phb: if there an issue if you cannot pass new version though 1.0 validator, given use of extensions?
<fjh> phb: is compatible
tlr: what I am saying is don't know if the subtleties
<fjh> relationship of namespace URI and schema URI
tlr: do not want to change the namespace but is useful to have a schema that can be used for validation.
<scribe> ACTION: tlr to take issue to the schema working group [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action17]
<trackbot> Created ACTION-153 - Take issue to the schema working group [on Thomas Roessler - due 2009-01-20].
<tlr> ACTION-153: "issue" is question around schema extension points
<trackbot> ACTION-153 Take issue to the schema working group notes added
<fjh> if new structures are in 2.0 namespace, put in extension points in current structure then can use 1.0 namespace
<fjh> hal: if not using new features can use what we use today
<general discussion, outcome that we are keeping the 1.0 schema intact and defining an extension schema but not consolidating the old an new schemas>
<fjh> tlr: question is how to validate 1.1 schema when we've defined schema for extension points, without changing namespace
<general discussion, we consider it ok to keep the schema identifier and change the conformance requirements but not the semantics>
<fjh> scott: define new schema with new namespace for new material that goes in extension, enabling validation
fjh: does this block first working draft
tlr: nop
hal: we are ok
<hlockhar> http://www.w3.org/2001/tag/doc/versioning-xml
<hlockhar> draft TAG finding which discusses this issue
<tlr> http://www.w3.org/2005/07/13-nsuri
<fjh> 2009
fjh: would like a 2009 series
tlr: why not www.w3.org/2009/xxxxxx
<tlr> http://www.w3.org/2008/11/xmldsig-ecc#
<fjh> tlr: notes benefit of consistency with 1.0, having #
<general attempt to work out why we have a # at the end of the proposed URI>
bal: remembers that the original idea was to have the ability to pull down the extension dymanically
tlr: would like a # simply for consistency
<klanz2> +1 to keep the #
phb: agrees (even though the # is ugly)
<fjh> www.w3.org/2009/xmldsig-ecc#
RESOLUTION: use a uri of the form www.w3.org/2009/xmldsig-ecc#
<scribe> ACTION: kyiu fix the URI in the document to www.w3.org/2009/xmldsig-ecc# [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action18]
<trackbot> Created ACTION-154 - Fix the URI in the document to www.w3.org/2009/xmldsig-ecc# [on Kelvin Yiu - due 2009-01-20].
<klanz2> @schema extension: http://www.xfront.com/ExtendingSchemas.html
<scribe> <done with versioning>
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0023.html
tlr: issue warning on MD5 needs to be more stern,
bal: the AES warning is a typo, should be AHS the hash standard that is long gone
tlr: should we add in a comment on security of SHA1 as well?
<scribe> ACTION: bal to update text on 6.2 to reflect contemporary cryptanalysis on MD5, SHA1 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action19]
<trackbot> Created ACTION-155 - Update text on 6.2 to reflect contemporary cryptanalysis on MD5, SHA1 [on Brian LaMacchia - due 2009-01-20].
<klanz2> @MD5: http://www.win.tue.nl/hashclash/rogue-ca/
<fjh> this action should take into account text proposed by thomas
sean: why do we have to mention MD5 when it was not in original
<its in the additional algs?>
tlr: original warning was mild, can drop it entirely
bhill: should there be a mention of the canonicalization with comments allows more scope for attack
<tlr> ISSUE: What should the best practices say about defenses against collision generation?
<trackbot> Created ISSUE-84 - What should the best practices say about defenses against collision generation? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/84/edit .
<scribe> ACTION: bhill to propose best practices for defending against collision generation... [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action20]
<trackbot> Created ACTION-156 - Propose best practices for defending against collision generation... [on Bradley Hill - due 2009-01-20].
<tlr> ACTION: bhill to draft proposal for ISSUE-84 [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action21]
<trackbot> Created ACTION-157 - Draft proposal for ISSUE-84 [on Bradley Hill - due 2009-01-20].
<tlr> ACTION-157 closed
<trackbot> ACTION-157 Draft proposal for ISSUE-84 closed
<tlr> ACTION-156: relates to ISSUE-84
<trackbot> ACTION-156 Propose best practices for defending against collision generation... notes added
fjh: may want to mention MD5 because mentioned earlier.
<klanz2> @bestpractices for hashing: When the generator of a message is not identical to the signer, the signer would have to change the message before signing not to trap into a prepared colission ... when the signer signs a collsion he create himself he is bound to both versions of the colision anyway ...
bal: two issues, one is signature generation, another is reference generation which is where we use digests by themselves.
scantor: known vulnerabilities (e.g. MD5 should not be used)
<fjh> need to fix in 1.1 signature errata item
<fjh> http://www.w3.org/2008/06/xmldsigcore-errata.html
<fjh> RFC reference changes, separate normative and informative references
fjh: need to do updates to
citations (RRCs supreceded etc.)
... can do a 1st working draft before this has been done.
<tlr> ACTION-2 closed
<trackbot> ACTION-2 Update XML Signature errata to reflect RFC version's reference changes, based on input from Don Eastlake closed
tlr: not just the rfc, is the whole thing.
<tlr> ACTION: thomas to take pass through references in Dsig Core - update, split into normative/informative [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action22]
<trackbot> Created ACTION-158 - Take pass through references in Dsig Core - update, split into normative/informative [on Thomas Roessler - due 2009-01-20].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0000.html
<klanz2> There is something in XAdES right ...
<klanz2> http://uri.etsi.org/01903/v1.3.2/XAdES.xsd
Kyiu: should we have a signature info properties for OCSP token
fjh: don't want to hold up 1st public draft for this
<klanz2> see OCSPValues, OCSPValuesType, EncapsulatedOCSPValue, EncapsulatedPKIDataType
<klanz2> in XAdES ...
tlr: not desirable to hold up 1.1.
fjh: should deliver in time for
Web apps etc.
... want to go to first WG draft with all the docs at same
time.
... one more issue for XML encryption 1.1
<fjh> http://www.w3.org/Encryption/2002/12-xmlenc-errata
fjh: when you publish an errata it is not normative for old version but becomes normative at new version
<review errata for encryption, they are all editorial or errors>
<scribe> ACTION: kyiu to include errata into the 1.1 documents [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action23]
<trackbot> Created ACTION-159 - Include errata into the 1.1 documents [on Kelvin Yiu - due 2009-01-20].
fjh: that is us done with sig and
encryption 1.1
... test cases and interop
fjh: need to define test cases and decide how going to organize, separate mailing list or not.
bal: may have non members looking to participate
kyiu: need to determine what we can participate on.
<pdatta> oracle will participate in the ECC XML sig 1.1 interop
smullan: is question do we have ECC implementation or will we ... have native implementation but not a java implementation
<brich> ibm cannot commit to participate in anything involving ECC
tlr: if the changes are such that
the things we have in FPWD are
... interop becomes critical in 3-4 months but not ciritical
for FPWD
fjh: if we hit 3 months and it is then critical we are in mess
<kgraf> ibm cannot commit to participate in anything involving ECC
<kgraf> intel
fjh, tlr: general discussion of pattent policy
fjh: is not an issue for FPWD,
<tlr> ACTION: thomas to check on possibility for external RF commitments under patent policy [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action24]
<trackbot> Created ACTION-160 - Check on possibility for external RF commitments under patent policy [on Thomas Roessler - due 2009-01-20].
fjh: want to avoid proliferation
of URIs
... most are in dsig, encrytion or more
<shivaram> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/
<fjh> phill: hmac not cryptographic primitive, say MAC instead
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0013.html
<scribe> ACTION: kyiu fix AES 256 reference in block cipher table
<trackbot> Created ACTION-161 - Fix AES 256 reference in block cipher table [on Kelvin Yiu - due 2009-01-20].
tlr: section 9, is not consistent
kyiu: these are key retreival mechanisms
<fjh> scott: value for retrieval method type, section 9
scantor: one of the keyinfo methods are retrieval methond and there is a type in there which is what you get back when you derefference the URI
fjh: heading should be Retrieval method types
<fjh> RetrievalMethd Type Values
<scribe> ACTION: kyiu to section 9 to be headed RetrievalMethd Type Values [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action25]
<trackbot> Created ACTION-162 - Section 9 to be headed RetrievalMethd Type Values [on Kelvin Yiu - due 2009-01-20].
<scribe> ACTION: kyiu to section 3 to be headed MAC [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action26]
<trackbot> Created ACTION-163 - Section 3 to be headed MAC [on Kelvin Yiu - due 2009-01-20].
<klanz2> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/#canonicalization-uris
<klanz2> is missing:
<klanz2> http://tools.ietf.org/html/rfc4051#section-2.4
<klanz2> http://tools.ietf.org/html/rfc3075#section-6.5.1
<klanz2> Minimal Canonicalization
<fjh> tlr: add text for each item, introducing
??? shouild we have whether these are required, recommended or whatever
FJH: should not put normative text in here
<fjh> scott: title of doc noting not Algs but URIs
fjh: want to avoid duplication and possibility of introducing errors
brich: do not want normative in a note
<klanz2> also Schema Centric Canonicalization is missing:
<klanz2> http://uddi.org/pubs/SchemaCentricCanonicalization-20050523.htm
<fjh> phb: need warning that does not mean
<fjh> klanz: avoid being authority
klanz2: need to avoid giving impression that mere inclusion makes this OK
scantor: either you want to maintain a registry or you don't
hal: we are sharing our lunch with the folk next door!
fjh: OK break for lunch till
1:30
... each of these documents need an intro to say what is going
on and they are not normative
<scribe> ACTION: scantor to write headings for each section to expand definition, explain not normative etc. [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action27]
<trackbot> Created ACTION-164 - Write headings for each section to expand definition, explain not normative etc. [on Scott Cantor - due 2009-01-20].
agreement for the agorithm doc to specify algorithms that are not normative but informative
is in discussion
<fjh> discuss adding column indicating REQUIRED/OPTIONAL etc
Thomas makes a suggestion - that as part of his action to try this and see how it works - to make a draft
Thomas is proposing a restucturing
Fredrick proposes this to be published with 1.1
Discussion of the creation of a note vs a wiki.
<fjh> I am not necessarily supportive of a restructuring
<fjh> sean noted that wiki might be alternative to static document
<fjh> scott: put summary into 1.1 document
scott: there is a need to enable people to find the appropriate documentaiton. it is more usful int the document.
scott: there is a need for a persistent reference
Thomas: a need for a process to be able to review it
<tlr> ACTION: thomas to propose changes to algorithms draft [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action28]
<trackbot> Created ACTION-165 - Propose changes to algorithms draft [on Thomas Roessler - due 2009-01-20].
Some items are missing from the list as it stands now - XPath filter2
<fjh> phb: additional algorithm can be discussed in 2.0
a need to specify CMAC-AES
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0013.html
SCott: Scott raised the issue - will we be maintaining this?
"at the time of approval.... this is the list.."
scott: the security group is not committing to maintain this list.
we need to add some algorithms, but we have the list.
<fjh> way forward is URIs for XML Security known at the time of 1.1 publish
Thomas does not want this on the critical path.
Fredrick wants to publish our work soon, and not extend this.
we could use IANA to register agorithms.
Frederick: comments on updating the properties
to have some properties common to security that can be used by other groups.
<csolc> link please
compliance - a common set of properties for conpliance.
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/Overview.html
further explanation of the mobile code portion.
some of this is not policy, but it is related to the application.
<fjh> phill: cert expiration does not invalidate signature earlier
a discussion of the fact that an expired cert does not cause the signature to expire.
<csolc> may also want to add Legal Content Attestations, reason for signing and contact info of the signer
<csolc> yes
<csolc> link?
<scantor> http://dev.w3.org/2006/waf/widgets-digsig/
<fhirsch3> http://dev.w3.org/2006/waf/widgets-digsig/
Frederick - going through the Widget signature document
Scott that the object tag is missing from the example just before 6.2
Brian: Signature Properties validation - a group of optional extentions - signed properties that have the implementation behave in specific way. an issue of critical and non-critical extentions. the standard has to be specific what to do to validate it.
Sean: in the original spec - the signature properties were not required. a profile can be impose a profile. as a general matter, signature properties are not critical
Brian: there were no signature
processing rules associated with signature properties.
... how do we know if a signature peoperty works or fails?
<fhirsch3> brian notes properties does not say how to tell it succeeds, validates
sean: this is too much, that you must support all or none is too much. this is in the document. this is clarified to say that for those USED you need to be able to support them as specified.
Phil: comparing this to SAML
Chris: properties as extentions to the validation these can be essention if used in a signature..
Frederick: if a property is needed then perhaps this property shoujld be part of the signature profile.
SCott: he could see this as plug-ins and call backs
<fhirsch3> scott - properties need to be discrete, can support or not. Profile, e.g. widgets, can require properties
<fhirsch3> deployment profile, not required by generic spec.
sean: to be careful because this may be part of a deployment profile. to make sure each part stands on its own
Sean: we should not specify that all of these are required.
<fhirsch3> each property can be supported or not, profile says what is required
<fhirsch3> phill: not make everything by default critical
Scott: it seems as thought the document as it reads now requires all of the properties.
<csolc> +1
a generis notion of extension. we need to specify sucess criteria for each aspect of signature properties.
a need for this to be in the application domain?
<fhirsch3> scott notes avoid unanticipated requirements on core processing
<Zakim> tlr, you wanted to also talk about inability to distinguish "common" from "other" properties and to also talk about when expiration might not work
we need to get it clear for people writing the API .
Thomas: the original says that signature properties are NOT critical, this draft specifies that this is critical.
a discussion of reference time.
Phil: wrap things in SAML assertions
<tlr> thomas: expires property should talk about a reference time, not current time -- what time you want to evaluate expiry against depends on the use case
<fhirsch3> bal: widgets do not have reference for DSA-SHA256, FIPS-186-2 mandates key length 1028 bits
<fhirsch3> bal: need 186-3
1- SHA256 is Goodness but it needs to be matched with DSA-2048 or better. (DSA-1024 is in pretty much the same bucket as RSA-1024, that is, both are nearing EOL.)
prefer to see ECDSA-256 with SHA-256
requirement of signatures algorithms
1024 was the required algorithm
Phil: to remove DSA, but Brian brought up that keylength has increased with newer versions.
there are interoperability testing problems with ECDSA-256
the advice is to try to get ECDSA to be able to use that.
<fhirsch3> bal: DSA will be federal standard, question of implementations
Brian: there are non-technical issues with ECDSA
<fhirsch3> bal: ECDSA will have vendor support, but may have other issues
a discusson on how small a platform needs to use this.
<PHB> If you have enough space to implement two signature algorithms, you ain't got a constrained platform
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Oct/0032.html
Brian: how small an attack surface can we make
Pratik: two pass is easier than holding the whole document - a DOM tree
RESOLUTION: to put simple signing on hold
for simple clients we need a simple means - not to simplify C14N
<fhirsch3> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm
<fhirsch3> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/Overview_diff.htm
starting with Encryption
the complex type element problem was fixed
We are starting to discuss signature
in section 6.2 Kelvin is using Brian's text
the first two paragraphs of section 6.2 will remain
<fhirsch3> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-MessageDigests
this is Brian's text that people agreed to.
<fhirsch3> shivaram : propsal to remove "Although both algorithms are REQUIRED,"
scott: we need to encourage SHA-256
use stronger language for SHA-256
RESOLUTION: to accept the language for section 6.2 as provided by Kelvin
a discussion of RFC 4050 interoperabilty
Frederick: we are recommending a profile for rfc 4050
<fhirsch3> shivaram: proposal for 4.4.2.3.2
shivaram: an issue of distinguishing between recomended and must.
<shivaram> "if one supports the below profile of the ECDSAKeyValue element as defined in [RFC4050], then they may be able to achieve interoperability with implementations supporting the same
<shivaram> "
<fhirsch3> supporting the following profile of ... can be used for interoperability with legacy applications
<tlr> "Implementations that need to support the RFC 4050 format for ECDSA keys can avoid known interoperability problems with that specification by adhering to the following profile:"
in section 4.4.2.3.2 - strike the portion in 1 after "more than 18 digits".
<fhirsch3> scott add similar sentence for x509 issuer serial
<fhirsch3> xsd part 2 restricts to 18 digits in part 2
<tlr> ACTION: scott to address X.509 issuer serial number length [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action30]
<trackbot> Created ACTION-166 - Address X.509 issuer serial number length [on Scott Cantor - due 2009-01-21].
<tlr> (for after this)
RESOLUTION: accept XML encryption and signature 1.1 with changes
<fhirsch3> tlr asks if 18 limit impacts people, scott says yes
<fhirsch3> issue: add note to dsig 1.1 re 18 digit limit for x509 issuer serial nmber
<trackbot> Created ISSUE-85 - Add note to dsig 1.1 re 18 digit limit for x509 issuer serial nmber ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/85/edit .
<fhirsch3> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/Overview.html#digest-method-uris
the section on C14N needs to be corrected.
<fhirsch3> sean and scott suggest removing section on key values
<scantor> suggested intro text for algorithms draft
<fhirsch3> defined with each algorithm
<tlr> kelvin, thomas: The important point is the linkage between algorithm and keyinfo type
<tlr> thomas: I think I can do this as part of the existing action item
<scantor> suggested intro text:
<scantor> "The various XML Security specifications have defined a number of algorithms of various types, while allowing and expecting additional algorithms to be defined later. Over time, these identifiers have been defined in a number of different specifications, including XML Signature, XML Encryption, RFCs and elsewhere.
<scantor> This makes it difficult for users of the XML Security specifications to know whether and where a URI for an algorithm of interest has been defined, and can lead to the use of incorrect URIs. The purpose of this Note is to collect the various known URIs at the time of its publication and indicate the specifications in which they are defined in order to avoid confusion and errors.
<scantor> This note is not intended as an exhaustive list of all known related identifiers, some of which may have been defined by other standards or specifications. Furthermore, this note is not to be taken as normative regarding the information provided; if information here conflicts with the referenced specification, the specification takes precedence in all cases."
RESOLUTION: we accept the text from scantor as written
XPATH Filter 2 is missing.
<fhirsch3> sean xpath filter 2 needs to be added, incorrect c1n4n refs
<tlr> http://www.w3.org/TR/xmldsig-filter2/
on break now, until :30
<fhirsch3> change from thomas, defer further changes from scott until then
<fhirsch3> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jan/0003.html
two agenda items
EXI tests c14n as the same speed of XML DOM serialization.
EXI serializatoin is faster than XML serialization.
adapt benchmark to use DOM
EXI has more benefit than just c14n exi on the wire - you do not have to send nonsignificant whitespace
<fhirsch3> scantor; how do you know what is non-signficant whitespace
<fhirsch3> taki: need schema
does EXI have a non - scema mode serialization? yes
EXI can be used with or without schema
Pratik: how important is the scema?
John: you get the same performance result with or without the schema
Thomas: there is a problem with
the 18 digit length specification for schema
... are there any length limits in EXI?
John: there is no length limits.
THomas: this is for validation
John: there are some limits for
floating point numbers
... has anyone carried out tests?
Pratik: he has done tests
<fhirsch3> ed simon exi use case summary - http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/att-0025/EXI_Use_Case_Review.html
Pratik: for signature: you might
combine c14n and digesting together.
... he agrees that it is no faster than DOM serialization
John: this is the known reference point
to compare to exi c14n
EXI Use Cases
Mike: he compared the EXI use cases
Ed: the methology for the use
cases was the expected use for signatures and encryption
... they also used military use cases
<esimon2> http://lists.w3.org/Archives/Public/publicÂxmlsec/2008Sep/0005.html
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0005.html
<tlr> (seems to work again, actually)
Ed: to use EXI encoded data. To use EXI for "plain" xml data. To use EXI compatable sigs and crypto for EXI data
to move to EXI and use that for signature and encryption.
Hal: exi should not define encryption and signatures
but use work from other groups
<fhirsch3> hal: but could use new version, e.g. not "existing"
<fhirsch3> john: concurs
<fhirsch3> john: question in use case document of not whether signing or encryption needed, but rather whether additional signature and encryption binary format needed...
ed: it is not a question of not needing signatures and encryption, but to have a means to apply this to EXI, and potentially if a new version is needJohn.
John: the need to use this for military applicaitons - simple compatability is not enough
ed: a need to try out these methods to understand the issues.
<esimon2> From Ed's report: "The real question though is not so much whether signability or encryptability is needed but, where they are needed, how should XML Signature and XML Encryption work with EXI. As a starting point, I think this comment in the âContentÂBased Routing and Publish Subscribeâ use case is well said: âIt is important to note that mere compatibility with existing XML Signature and XML Encryption Recommendations without considerable advanc
<fhirsch3> issue: document performance criterial and benchmarks
<trackbot> Created ISSUE-86 - Document performance criterial and benchmarks ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/86/edit .
John: there have been tests involving military applications and customers
Frederick: how much use does EXI use XML transforms?
John: he does not know if they are using transforms. they would be mostly independent of EXI, they are in the memory model, rather than the wire format
the transforms are on the memory model
is there application of XPath?
yes, you can do normal operations, EXI fits below the lowest level of the APIs
ed: XSLT transforms can be used.
<fhirsch3> transform note, editorial draft http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
ed: use of transforms does not have a large impact. (xslt applied to the data model, and serializer the EXI directly)
<esimon2> I think the above statement should be attributed to John
Pratik: we may need to define a native EXI enrcyption.
<esimon2> +1 to Pratik
Frederick: can the cypher data be in EXI format?
<fhirsch3> pratik notes can the cipherdata serialization be an exi serialization rather than xml, would this be of value in exi environment
<fhirsch3> john notes this might be of value
hal: we may need to address this as if encrypting a BLOB (in binary)
<fhirsch3> 4.1 bullet 3.1 in xml encryption - xml serialization
Thomas: do we spit this out in octets"
?
<fhirsch3> http://www.w3.org/TR/xmlenc-core/#sec-Processing-Encryption
<fhirsch3> If the data is an 'element' [XML, section 3] or element 'content' [XML, section 3.1], obtain the octets by serializing the data in UTF-8 as specified in [XML].
John: to define another type : EXI encrypted data
<fhirsch3> encrypting xml encoded as exi
Hal: we may have a free-standing document - an EXI specific document for encryption and signature
<fhirsch3> may need to define how to integrate exi and xml security in general terms
<fhirsch3> with some details
Hal: we will have to define how
we have an EXI document that has some portions encrypted
... does EXI also include schema type information? Do we need
the metadata for EXI processing?
John: you could do that with the Schema ID
you could put this in the header
<esimon2> Not me talking!
s/ed/john/The scema ID could be the schema.
john: The schema ID could be the schema.
<fhirsch3> hal notes metadata could have security requirements for integrity etc
<hlockhar> exi files can contain metadata such as the schema identifier
Taki: The documents are in last call phase.
<hlockhar> assuming we define exi-specific encryption and signature, we need to think about how the metadata gets handled
<hlockhar> for example, we might chose to always encrypt the metadata when any part ot the document is encrypted
<hlockhar> or encrypt it sometimes or give the application a way to specify what to do
John: is the intent that the encoding describes transfer or content?
<fhirsch3> http://www.w3.org/TR/xmlenc-core/#sec-EncryptedType
<hlockhar> I am particularly worried that it was mentioned that there is a mechanism to put in any sort of metadata they might want to (presumably to make processing work better)
<hlockhar> there is no way to know in advance what security properties such user defined data requires
scott: his reading is that the current type - refering to say an element - the only references to encoding are for non-xml
<fhirsch3> http://www.w3.org/TR/xmlenc-core/#sec-Processing-Decryption
<fhirsch3> Process decrypted data if Type is unspecified or is not 'element' or element 'content'.
Thomas: (discussion on the wording of the processing model addressing encoding)
<fhirsch3> tlr: might need to define new Type attribute value, deal with optionality
scott: the ability to use type is constrained to a function.
Thomas: to use type as an extention model to mirror content and element model of EXI
<tlr> Type is probably the right extension point from the processing model. HOWEVER, you'd probably have to mirror 'element' and 'content' separately, which suggests that the right extension point isn't in the spec right now. Ick.
Taki: the time frame is later this month.
<tlr> 2-6 November 2009, Santa Clara Marriott, Santa Clara, CA, USA (in conjunction with AC Meeting) [confirmed*]
we need a face to face meeting between now and November
<tlr> ACTION: thomas to set up questionnaire about meeting locations and times [recorded in http://www.w3.org/2009/01/13-xmlsec-minutes.html#action31]
<trackbot> Created ACTION-167 - Set up questionnaire about meeting locations and times [on Thomas Roessler - due 2009-01-21].