XML Security Working Group Teleconference
10 Feb 2009

 

 

<trackbot> Date: 10 February 2009

<fjh> zakin, aadd is sena

cribenick pdatta

<tlr> ScribeNick: pdatta

<tlr> zkim, who is muted?

<tlr> Scribe: Pratik Datta

Administrative

juan carlos to scribe next week

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

<fjh> Patent Policy FAQ on Normative References

<fjh> tlr notes, "not publishing" means not turning into a Recommendation

tlr: heard different opinions from different peopple

<fjh> Please review and mark pending/complete open actions for 1.1

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

<tlr> tlr: note that I don't have any opinion on whether or not ECDSA is encumbered; I have heared different opinions from different corners

fjh: please close action items this week
... please fill up questionnaire for F2F
... if you have done your action, mark it pending, don't leave it open

<fjh> Interim F2F Questionnaire

<fjh> http://www.w3.org/2002/09/wbs/42458/f2fsched2009/

minutes approval

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

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

magnus: confusion on the long discussion about EC structurres

fjh: put a link to magnus's message in the minutes

bal: looked at issue on EC Point conversion

<tlr> action-203?

<trackbot> ACTION-203 -- Brian LaMacchia to check on proper EC Point conversion reference -- due 2009-02-10 -- OPEN

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

bal: what exactly is ACTION 203

fjh: bal's action is to investigate what he thinks we should do for ECPoint

<jcruella> just joined the call.... apologies for the delay

fjh: tlr to edit minutes to add magnus's comment about minutes as a link

Document status

<fjh> Requirements

<fjh> RetrievalMethod, Exclusive C4N added, updated examples

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

<fjh> XML Security Algorithm Cross-Reference Editors Draft

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

tlr: Updated algorithms
... made clear what the input and output for algorithms are
... trying to make it into a useful cross reference

fjh: are we ready to publish as working draft

<fjh> tlr could add more algorithms from 4051

<fjh> Best Practices

fjh: after next week's call, we are hoping to go to first public working draft

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

fjh: added long term signatures at a high level and scott's proposal on schema normalization
... in best practices document

XML Signature 1.1

<fjh> ECC Algorithms Schema update

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

magnus: email hilights differences and once again clarifies the proposal and
... has use case for requiring this separate structure

<bal> i object

bal: magnus and I had a side thread on other EC issues
... what PKIX has been doing
... PKIX has deprecated anything other than named curves

<fjh> bal notes that this is argument to keep compact form

bal: ANSI hasn't deprecated non named curves
... should we bloat something that is already deprecated in PKIX
... do we optimize for the common case

magnus: PKIX has deprecated it, but PKIX draft is a profile of X9 62
... PKIX says you can use the full form, if you need it
... need the ability to express more flexibily

<bal> Here's the PKIX draft I mentioned: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt

PHB-VISTA: only group that is not using named curves is german group - brain curves
... group of people defining named curves, and another group using those named curves

<fjh> phill notes that named curves removes unnecessarily flexibility and allows pre-optimization

PHB-VISTA: don't describe the curves each time

<fjh> phill supports bal approach

PHB-VISTA: go with brian's proposal - only use named curves

bal: neither of us is saying that we only support named curves
... this will be a third option

PHB-VISTA: if you expect everybody to use named curves , why discuss about these two options

bal: the proper way to fix this is to use Substitution groups
... but this is may not be allowed in Relax NG
... also it brings in lot of heavy XML schema

PHB-VISTA: SAML uses substitution groups

<scantor> scantor: substituion is very tough on implementations, SAML 2 blocks it in all its schemas

bal: two options lets vote - one option more modular, second option optimized for common case

klanz2: we used named curves as well

<tlr> zakim unmute me

tlr: simply put three choices on IRC and let people vote

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

<tlr> choice a) current design as described in that e-mail

<tlr> choice b) proposed alternative design as described in that e-mail

<tlr> choice c) abstain

<magnus> I vote b)

<bal> Choice A

<tlr> c

<fjh> c

<kgraf> intel votes A

<PHB-Vista> Choice A

<scantor> c

<brich> c

<jwray> c

<hlockhar> C

<smullan> c abstain until we can implement

<klanz2> b)

<bhill> a)

pdatta: a)

<fjh> is there anyone who could not live with A?

<fjh> no response

<fjh> Preference for A - 5, preference for B - 2

<klanz2> is there someone who could not live with b?

<fjh> Abstain - 8

magnus: just leave the current draft as is, but add this an editors note that there has been discussion about alternative design
... but we don't present it as two alternatives

tlr: it is the chairs prerogative to call a resolution
... the resolution can be revised based on new information
... what can be resolved in a public review that we have't already considered

<fjh> possible resolution - the WG accepts preference A and adds an editors note to the draft noting that alternatives have been considered, including link to magnus email

<tlr> ACTION: thomas to draft editor's note concerning ECDSAKeyValueTyp [recorded in http://www.w3.org/2009/02/10-xmlsec-minutes.html#action01]

<trackbot> Created ACTION-208 - Draft editor's note concerning ECDSAKeyValueTyp [on Thomas Roessler - due 2009-02-17].

fjh: it is important to have anote about the alternative - because some information can come after implementations have been done

bal: this is our chance to get feedback, let's ask
... as notes or as side documents

<fjh> RRSAgent: where am I?

RESOLUTION: the WG accepts preference A and adds an editors note to the draft noting that alternatives have been considered, including link to magnus email

Signature 1.1 algorithms

<fjh> add as recommended algorithms "XPATH 2 Filter" and "Exclusive Canonicalization

<fjh> Canonicalization" to the list in section 6.0

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

tlr: I owe text on XPath 2 filter

<tlr> ACTION-196

<tlr> ACTION-196?

<trackbot> ACTION-196 -- Thomas Roessler to draft text on section 6.1 about XPath, XPath Filter 2 and XSLT best practices -- due 2009-02-10 -- OPEN

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

Whitespace removal in XML signature 1.1

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

scantor: this is the original XPAth transform. not XPath Filter 2
... should not have to use XPAth to deal with white space

<fjh> scott notes supportive of second part of proposal, references, not first part, SignedInfo

tlr: two comments - first one is cosmetic
... child elements are parameters for an algorithm

<scantor> +1, I was going to ask about that next

tlr: suggesting pre transform changes things in a very serious way
... code would have to change significantly , can't use dispatch model

<fjh> tlr notes that first part inconsistent with current c14n parameter model, could consider changing cn14n but maybe later.

tlr: transform is better, but it can't be used in a SignedInfo
... make whitespace removal as a named transform

<fjh> tlr risks with proposal to interoperability, cost of changing, small benefit, argue to defer

tlr: significant cost to interoperability

<tlr> +1 to pratik

<fjh> pdatta notes that canonicalization is big issue, even if this looks like small change, thus requires thought

<tlr> this changes the meaning of markup

<fjh> +1 to pratik and tlr

klanz2: I don't see the risk, if the signature was indented it would break anyway

bal: Is the ds11: removewhitespace an optional or mandatory

<fjh> bal notes if not mandatory cannot have interop, if so then a 2.0

bal: if it is mandatory, then it breaks the schema
... if it is optional then it won't interoperate

tlr: the chilren of an algorithm are not owned by the signature

<fjh> thomas repeats - children of an algorithm are defined by the algorithm, as a parameter. thus cannot be defined by signature.

tlr: they are owned by the algorithm itself

<klanz2> so put it to c14n

<klanz2> I see

<klanz2> so c14n 1.2

<klanz2> ... I see

tlr: we have a long standing agreement on who owns the parameters

<klanz2> so whre to put this stuff and yet remain backward compatible?

<fjh> proposed resolution: not accept proposed change to Whitespace Removal in ds:SignedInfo due to need to update canonicalization for this parameter

<tlr> works for me

klanz2: want this as a requirement in 1.1

fjh: not hold up publication of drafts currently planned for publication

klanz2: this is one of the top issues for users

<fjh> resolution: not accept proposed change to Whitespace Removal in ds:SignedInfo due to need to update canonicalization for this parameter

tlr: continue conversation on email

OCSPResponse in 1.1

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

<tlr> http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0022.html

<tlr> action-178?

<trackbot> ACTION-178 -- Sean Mullan to draft text for v1.1 on OCSPResponse subelement for X509Data -- due 2009-01-22 -- PENDINGREVIEW

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

<tlr> o The dsig11:OCSPResponse element contains a base64-encoding of a DER-encoded

<tlr> OCSP Response [OCSP].

<tlr> Schema Definition:

<tlr> <!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->

<tlr> <element name="OCSPResponse" type="base64binary"/>

<tlr> Appendix:

<tlr> OCSP

<tlr> RFC 2560. X.509 Internet Public Key Infrastructure Online

<tlr> Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani

<tlr> S. Galperin, C. Adams. June 1999.

<tlr> http://www.ietf.org/rfc/rfc2560.txt

<tlr> [Sean Mullan]

smullan: contains base64 encoding of DERencoding of OCSP Response

<bal> looks ok to me

<tlr> ok with me as well

smullan: incorporated comments from magnus and tlr

RESOLUTION: accept proposal from smullan on OCSP Response

<tlr> ACTION: thomas to incorporate ACTION-178 into draft [recorded in http://www.w3.org/2009/02/10-xmlsec-minutes.html#action02]

<trackbot> Created ACTION-209 - Incorporate ACTION-178 into draft [on Thomas Roessler - due 2009-02-17].

RetrievalMethod type

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

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

tlr: in 4051 stumbled over bunch over RetrievalMEthod identifiers
... might make sense to mention identifiers for those elements that we define, also happy to leave things as they are

smullan: ok with putting them in algorithms document, but not in 1.1
... putting in 1.1 means we have to implement it and write tests

RESOLUTION: add RetrievalMethod Type URI reference into algorithms note, don't add them to XML Signature 1.1

<tlr> ACTION: thomas to put RetrievalMethod Types from RFC 4051 into xmlsec-algorithms [recorded in http://www.w3.org/2009/02/10-xmlsec-minutes.html#action03]

<trackbot> Created ACTION-210 - Put RetrievalMethod Types from RFC 4051 into xmlsec-algorithms [on Thomas Roessler - due 2009-02-17].

Section 6.6

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

tlr: extract what input and outputs various transforms have
... not very clear about it

<fjh> issue: clarify inputs and outputs, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0029.html

<trackbot> Created ISSUE-97 - Clarify inputs and outputs, see http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0029.html ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/97/edit .

tlr: e.g. this algorithm needs octet stream or nodeset, if we get octet stream convert to nodeset, but the algorithm only works with nodeset
... need to cleanup the text

bal: three actions on EC Point

Elliptic curve issues

<fjh> http://www.w3.org/2008/xmlsec/track/actions/203

<fjh> http://www.w3.org/2008/xmlsec/track/actions/204

<fjh> http://www.w3.org/2008/xmlsec/track/actions/191

bal: you are dealing with points on a curve
... you take the x, y poins on a curve , concatenate them into one octet stream
... approach we took is more like RSA, we break up the X and Y

<fjh> magnus noted alternative approach - http://lists.w3.org/Archives/Public/public-xmlsec/2009Feb/0016.html

bal: few months ago issue came up whether we should support RSA with the numbers combined in binary structure

magnus: If you do EC Point as an octet stream you save some space

fjh: doesn't combining it make is easier for implementations

bal: I am not sure, that structure is not ASN1, it is not described by the schema
... RFC 4050 is more heavywight, it does additional hex encoding
... this one keeps in line with original RSA key value

magnus: RFC 3279, X 9.62, and SEC 1 all do it in the combined EC Point way

bal: we should not support for Point compression in the specification

<brich> +1 to SHOULD NOT

bal: spec should not say implement X 9.62, because that requires point compression

<tlr> magnus: do not want to require point compression either

magnus: 3279 say that you should support uncompressed form
... for interop, PKIX required implementation to support uncompressed form
... so if you send compressed form, it may not be accepted unless the receiver also supports it

bal: no separated OID structure for compressed form

fjh: where are we going with this - are we all agreeing on uncompressed form

bal: options 1) X, Y are separate, 2) X and Y are combined but uncompressed, 3) X and Y are combined and compressed

<fjh> wg agrees not to have #3

bal: not a huge deal between 1 or 2
... 1 is inline with RSA Key value

magnus: it will be beneficial for our implementation to have X and Y combined

bal: schema purists have any opinion on having complex binary structures? they are not ASN.1

fjh: what is the benefit of having X and Y separate, if you are feeding them combined into the algorithm?

bal: possible benefit if you are doing any checks on the X and Y value

magnus: those checks are made in the crypto library
... so they can work with combined X and Y

fjh: can we adopt magnus's proposal now ?

<fjh> proposed resolution - bal to implement magnus proposed change unless major issue

RESOLUTION: bal to implement magnus proposed change unless major issue

Hash

<fjh> had agreement to include

magnus: change in X9.62 between original version and new version for hash element

<fjh> ACTION: bal to update elliptic key value to magnus approach after checking that no major issue [recorded in http://www.w3.org/2009/02/10-xmlsec-minutes.html#action04]

<trackbot> Created ACTION-211 - Update elliptic key value to magnus approach after checking that no major issue [on Brian LaMacchia - due 2009-02-17].

<fjh> ACTION: magnus to provide bal hash text [recorded in http://www.w3.org/2009/02/10-xmlsec-minutes.html#action05]

<trackbot> Created ACTION-212 - Provide bal hash text [on Magnus Nyström - due 2009-02-17].

Whether Elliptic curves are optional or required in first public draft

bal: haven't heard strong opinion on why not have it required

fjh: questionnaire will help