See also: IRC log
<trackbot> Date: 27 January 2009
fjh: shouldn't do this week,
people have not had time to review f2f minutes
... defer to next week
<fjh> document status and links, http://www.w3.org/2008/xmlsec/wiki/PublicationStatus
fjh: widgets and properties updated, still much work to do on properties and processing model
<fjh> updated widget signature - http://dev.w3.org/2006/waf/widgets-digsig/
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm
<fjh> Corrected Spelling Errors
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0036.html
<fjh> Adopt issuer serial text
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0039.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0046.html
scantor: update language around
serial. random serials are becoming common to deal with
collision attacks
... also update to address rfc 4050 schema
<bal> I like many over some
bal: Stick with suggested wording of "many" CAs over "some"
<fjh> scotts proposal with additional change, "may not support integer types with decimal data ..."
<fjh> RESOLUTION: Adopt Scott's proposal with additional change, "may not support integer types with decimal data ..." in both places
RESOLUTION: Adopt Scott's proposal with additional change, "may not support integer types with decimal data ..." in both places
<scribe> ACTION: bal to update proposal language for approval next meeting [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-186 - Update proposal language on issuer serial before next meeting [on Brian LaMacchia - due 2009-02-03].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0041.html
Magnus: in definition, there are two choices for definition of the curve
magnus: these are defined in a
number of ways, including by the CA
... schema should have a set of types to accomodate all
options, be more in line with x.962
... ecdomain parameter type
bal: not the goal to duplicate
x.962. implicit CA element allows to import curve parameters
from an issuing cert
... no certificate guaranteed to be present in an XMLDSIG
... would have to try to link between value in signature and
something in x509data blob
magnus: suggestion is to allow as
a separate type to allow more flexibility if ecdomain is used
in other contexts
... e.g. for encrypted data to avoid respecifying keys
... what is the disadvantage? e.g. to identify a specific
curve
bal: still not sure what the use case is in xmldsig, want to understand before opening the schema further
magnus: already changing the schema, only want to add one additional choice to key value type choice
scantor: from schema standpoint, better to avoid embedding content models and have a distinct type for each
<fjh> this is support for magnus's proposed change
<tlr> I think the consistency argument is the salient one here.
magnus: other change proposed is to include hash component to verify that curve was randomly generated
fjh: reluctant to make changes with kelvin absent, but will need to review at public working group anyway
bal: looking at rfc 3279, re: hash, there is an inconsistency between documents, no hash element defined there
magnus: originally implicitly sha1, now additional flexibility introduced
<fjh> http://www.ietf.org/rfc/rfc3279.txt
fjh: need to create distinct issues for this
magnus: should investigate why there is a discrepancy between IETF and x.962
<fjh> issue: include the "implicitCA" option for ECKeyValueType and separate ECDomainParameterType type
<trackbot> Created ISSUE-92 - Include the \"implicitCA\" option for ECKeyValueType and separate ECDomainParameterType type ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/92/edit .
<fjh> issue: missing a <Hash> element in the ds:ECParametersType type definition
<trackbot> Created ISSUE-93 - Missing a <Hash> element in the ds:ECParametersType type definition ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/93/edit .
magnus: if this is part of an evolving understanding from the original document, we should investigate why and if we need it
<fjh> issue: in the ECParameterType type definition, note that the <Order>element may also be a large number and hence the use of the"integer" type may again be problematic
<trackbot> Created ISSUE-94 - In the ECParameterType type definition, note that the <Order>element may also be a large number and hence the use of the\"integer\" type may again be problematic ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/94/edit .
bal: as long as serialization is the same, not a big deal
<scribe> ACTION: magnus to look into discussion archives behind x.962 changes [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-187 - Look into discussion archives behind x.962 changes [on Magnus Nyström - due 2009-02-03].
<klanz2> My Regrets, I can only attend via IRC ...
bal: if a new type is introduced, does that introduce a new tag and increase the size?
scantor: if inline, would add a new wrapper tag
bal: this would make all ec signatures larger, balance with benefits
<fjh> note scott echos concern about adding element, and size
magnus: addition is fairly minimal - xml is verbose as it is
scantor: still an extra layer, an annoyance
bal: object model in
memory...
... should definitely be cryptobinary, but need compelling use
case to add new elements
magnus: will look beyond consistency argument...
bal: need a concrete reason to increase signature size, xml not a license to just add stuff
<fjh> ACTION: magus to provide additional arguments for schema change [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action03]
<trackbot> Sorry, couldn't find user - magus
<fjh> ACTION: magnus provide additional arguments for schema change [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-188 - Provide additional arguments for schema change [on Magnus Nyström - due 2009-02-03].
<tlr> ACTION: magnus to provide additional arguments for schema change [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-189 - Provide additional arguments for schema change [on Magnus Nyström - due 2009-02-03].
<fjh> close action 189
<tlr> ACTION-189 closed
<trackbot> ACTION-189 Provide additional arguments for schema change closed
<tlr> ECPointType has cryptoBinary already
<tlr> CoFactor is integer, as is Order
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/xmldsig-ecc.xsd
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/xenc-schema-11.xsd
<tlr> and ds:PrimeFieldParamsType uses positiveInteger
bal: EC Prime Field, Order and
CoFactor parameter types are integer
... note that change to cryptobinary requires b64 encoding
<fjh> proposed resolution - change ECParameterType and PrimeFieldParameterType as cryptobinary
<tlr> ECParameterType/Order
PrimeFieldParameterType/P
<tlr> PrimeFieldParamsType/P
ECParameterType/Order
RESOLUTION: Change ECParameterType/Order and PrimeFieldParameterType/P from Integer to Cryptobinary
<scribe> ACTION: bal to update schema to make ecc changes from integer to cryptobinary and make changes to doc [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action06]
<trackbot> Created ACTION-190 - Update schema to make ecc changes from integer to cryptobinary and make changes to doc [on Brian LaMacchia - due 2009-02-03].
frederick: last point in magnus's mail on conversion from points to octet streams?
bal: no context yet, will have to look up
<fjh> The reference for conversion of an EC point to an Octet String would
<fjh> perhaps better be to Appendix A.5.7 ("Point to Octet String").
<scribe> ACTION: bal to research Appendix A.5.7 ("Point to Octet String") conversions for ECC [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-191 - Research Appendix A.5.7 (\"Point to Octet String\") conversions for ECC [on Brian LaMacchia - due 2009-02-03].
<fjh> ACTION: bal to review suggestion to change reference for EC point to OCtet string proposed by magnus [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-192 - Review suggestion to change reference for EC point to OCtet string proposed by magnus [on Brian LaMacchia - due 2009-02-03].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0043.html
tlr: is there a need for new algorithim identifiers given we are changing the markup for key identifiers?
<tlr> (in other words, I'm happy for this to be a short agendum)
tlr: thinking we don't need one
scantor: agree, this would be inconsistent - algorithm is stable
bal: +1
<fjh> general agreement is that no new uri is needed because algorithm is stable
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0047.html
tlr: clarify to say that the
transform may take either octet stream or nodeset and
differential behavior for each
... not intended to change meaning, only clarify for the
reader
<tlr> ACTION: thomas to add base64 clarification to dsig 1.1 http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0047.html [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-193 - Add base64 clarification to dsig 1.1 http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0047.html [on Thomas Roessler - due 2009-02-03].
RESOLUTION: accept tlr's proposed clarification of text for base64 clarification to dsig 1.1
<scribe>
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0050.html
GeraldEdgar: long lived security
for documents for regulated companies is necessary
... strength of algorithms in Suite B is sufficient for
commercial use for a longer length of time
... references in NSA Suite B are slightly different than those
in xmlsec
fjh: does it make sense to add references and keep existing?
GeraldEdgar: would be appropriate
<fjh> Elliptic Curve Digital Signature Algorithm - FIPS 186-2
<fjh> Secure Hash Algorithm - FIPS 180-2
<bal> DSS
<bal> FIPS PUB 186-2. Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology.
<bal> http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
<bal> FIPS 186-2 is reference "DSS" already
RESOLUTION: Add references to DSS/ECDSA FIPS 186-2 and SHA FIPS 180-2 to signature 1.1 document
<scribe> ACTION: bal to add FIPS 180-2 reference to signature 1.1. document [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action11]
<trackbot> Created ACTION-194 - Add FIPS 180-2 reference to signature 1.1. document [on Brian LaMacchia - due 2009-02-03].
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0063.html
brich: current position in 1.1
draft for sig+enc is that ECDSA and ECDH are REQUIRED
algorithms
... support this from a technology point of view, but IP around
these algorithms is murky at best
<tlr> brich: IBM generally does not support required algorithms with non-RF sorts of deals
<tlr> brich: also, please be aware of patent policy
<tlr> fjh: Note that publishing FPWD with REQUIRED does not imply we necessarily keep the algorithms as required
<bal:> Is IBM asserting that they might have IP on the algorithms? or are you concerned about 3rd party?
<brich:> 3rd party
<bal:> Specifically on implementations of ECDSA with prime curves only? ... fair amount of agreement on prime curves, since there seems to be consensus on IP state for those particular curves ...
bal: appears to be a reasonable consensus on IP state of NIST curves, specifically
<brich:> you are correct in that I'm constrained in what I can say
bal: have you seen public disclosures by any other parties in other forums that should be brought to our attention?
<brich:> I haven't done that much research on what other bodies have done.
tlr: patent policy has a precice
definition, now is not the time for this discussion as none of
us are lawyers, but will be happy
... to organize a discussion related to this issue about what
counts as an essential claim
fjh: next week we would like to
decide to publish first working draft, we may decide to keep
algorithms required, but do have an issue against it
... is this a major issue for you if we decide this and you
can't make the call?
... (to brich)
<fjh> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/Overview.html
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0065.html
<brich> the phone is cutting in and out, but I'll respond to the previous topic with "I will understand if the consensus is that we go forward with FPWD with my issue still outstanding"
fjh: how to see what the work that was done is
pdatta: will send a diff to members list
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Jan/0056.html
fjh: resolve to implement proposal into requirements draft
scantor: schema details not needed in document
RESOLUTION: implement algorithms proposal into requirements draft
<scribe> ACTION: fjh to update requirements document with algorithms proposal [recorded in http://www.w3.org/2009/01/27-xmlsec-minutes.html#action12]
<trackbot> Created ACTION-195 - Update requirements document with algorithms proposal [on Frederick Hirsch - due 2009-02-03].
<fjh> http://www.w3.org/2008/xmlsec/Drafts/derived-key/derived-keys.html
fjh: should review on next call
magnus: looking for feedback and review
<GeraldEdgar> thanks all.
RRSAgent make log member