See also: IRC log
<trackbot> Date: 18 January 2011
<Gerald-E> scribenick: Gerald-E
Cancel Feb 1 meeting
RESOLUTION: Cancel the teleconference 1 February 2011.
<fjh> Approve minutes, 11 January 2011
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/att-0030/minutes-2011-01-11.html
<tlr> ScribeNick: tlr
RESOLUTION: Minutes from 11 January 2011 are approved
fjh: Certicom sent a message to the public list.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0035.html
tlr: reached out to certicom; see message on public list for current status.
bal: sounds like that suggested license doesn't comply?
tlr: see previous discussion on patent policy; don't want to make legal pronouncements on detail level.
fjh: does anybody want to reopen question whether ECC is optional?
(crickets)
gerald: should have it in the standard, even if optional
magnus: see mandatory as a fundamental reason for doing the 1.1 work.
... in order to show interoperability and conformance with suite B, essential
pdatta: will we have text in the document about IPR?
tlr: this IPR falls a bit outside our routine workflow; trying to figure out publication pieces.
shivaram: shouldn't remove completely; optional better than removal
brich: Not a lawyer. Think that ECC should remain, but prefer optional. Real conflict between IPR cloud and desire to broadly integrate into standard as required piece. Optional causes fewer issues.
<fjh> question of degree to which optional versus mandatory relates to the IPR concern
gerald-e: process question. If we put it as mandatory now, can a PAG put us to optional?
tlr: umh
bal: don't think the question we're discussion is the one to ask right now
... the WG made decision a long time ago to pursue mandatory ECC
... fact that Certicom sent message with some statements one way or the other
... unless W3C says this changes their opinion
... the WG has features that are mandatory
... there's a process position here
... CR + PAG
... question is whether or not IPR statement would satisfy W3C policy
<Shivara> I like it this way: if we do optional and then start PAG in parallel. If the PAG makes this mandatory, then we publish a minor rev of the same
bal: at the end of the day, question (and it's a w3c question) is whether this changes W3C position. If it doesn't, don't want to have this conversation.
hal: in the event that a patent has been disclosed, a PAG *WILL* be launched, etc etc
... believe that condition exists
<fjh> proposed RESOLUTION: the WG reaffirms its decision to keep the ECC material mandatory in the specification as previously decided
fjh: proposed resolution to keep it mandatory. Any objections?
-- silence --
RESOLUTION: the WG reaffirms its decision to keep the ECC material mandatory in the specification as previously decided
<fjh> Information on PAG from W3C process: http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-PAG-formation and http://www.w3.org/2007/04/patent-exception-management
<scribe> ACTION: thomas to figure out publication mechanics around CR & ECC [recorded in http://www.w3.org/2011/01/18-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-770 - Figure out publication mechanics around CR & ECC [on Thomas Roessler - due 2011-01-25].
<fjh> Process for CR: http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
<fjh> Documents for CR: XML Signature 1.1, XML Encryption 1.1, XML Security Properties, XML Security Generic Hybrid Ciphers
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0039.html
fjh: there are four relevant documents; Mangus has done some detail-level review (editorial errors, references)
... I've made the requisite updates
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0047.html
<fjh> Need RFC for ECC-ALGS (but not a blocker for CR)
<fjh> Update 1.1 cross references when going to CR
tlr: we can deal with the draft-mcgrew reference as we go; not worried about transition call here
<fjh> tlr: will indicate in CR request the status of McGrew
magnus: RFC number allocated by end of January; publication as RFC might be slightly later
<fjh> Need additional review of Signature 1.1 and explain for it, Cynthia volunteered in the coming week
<fjh> ACTION-766?
<trackbot> ACTION-766 -- Brian LaMacchia to implement change for base64 -- due 2011-01-18 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/766
bal: didn't we take care of that? -- ooops, will do edit later today.
tlr: <features at risk mechanism and relevant process>
fjh: suggest we go through the specs one at a time, do CR exit criteria, features at risk.
... propose that exit criteria are 2 interoperable implementations for all features.
... other suggestions?
<crickets>
RESOLUTION: WG will demonstrate two interoperable implementations for all features, mandatory and optional
fjh: features at risk for the various specs...
tlr: note: there's a difference between "we think there are risks" and "we call it a feature is at risk"
scantor: there are some other features that were added late
fjh: KeyValue important, KeyInfoReference stay as well
scantor: ECKeyValue is really important
... think DEREncodedKeyValue isn't essential, but pretty sure we can get implementation experience for it
<fjh> proposed RESOLUTION: WG agrees to bring XML Signature 1.1 to Candidate Recommendation, incorporating proposed edits for base64 section, with no features at risk and exit criteria of two interoperable implementations for all mandatory and optional features
<fjh> proposed RESOLUTION: WG agrees to bring XML Signature 1.1 to Candidate Recommendation, incorporating proposed edits for base64 section, with no features at risk and exit criteria of two interoperable implementations for all mandatory and optional features with publication by 10 February.
<fjh> ScribeNick: fjh
RESOLUTION: WG agrees to bring XML Signature 1.1 to Candidate Recommendation, incorporating proposed edits for base64 section, with no features at risk and exit criteria of two interoperable implementations for all mandatory and optional features with publication by 10 February.
<tlr> tlr: on schedule -- publication within 3 weeks sounds realistic
for xml encryption 1.1, possible concerns with implementation ECDH KeyValues, AES Keywrap with padding, ECDH-ES, Derived Keys
<Gerald-E> fjh: is there anyting at risk?
<Gerald-E> bal: nothing is seen at risk at this point.
bal notes that interop is underway for derived keys
RESOLUTION: WG agrees to bring XML Encryption1.1 to Candidate Recommendation, with no features at risk and exit criteria of two interoperable implementations for all mandatory and optional features with publication by 10 February.
<Gerald-E> XML Security Properties
RESOLUTION: WG agrees to bring XML Signature Properties to Candidate Recommendation with the Created/Expires/ReplayProtect properties as "at risk" and exit criteria of two interoperable implementations for all mandatory and optional features with publication by 10 February
<Gerald-E> XML Security Generic Hybrid Ciphers
RESOLUTION: WG agrees to bring XML Security Generic Hybrid Ciphers to Candidate Recommendation, with no features at risk and exit criteria of two interoperable implementations for all mandatory and optional features with publication by 10 February.
<Gerald-E> fjh: the question is how to bring this to Rec
Publish update of 1.1 requirements and best practices
<Gerald-E> fjh: we need to update. the 1.1 requirements and best practices.
proposed RESOLUTION: Plan to publish update of 1.1 Requirements and Best Practices in conjunction with 1.1 CR publication
RESOLUTION: Plan to publish update of 1.1 Requirements and Best Practices in conjunction with 1.1 CR publication
<scribe> ACTION: fjh to review 1.1 requirements issues with Magnus [recorded in http://www.w3.org/2011/01/18-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-771 - Review 1.1 requirements issues with Magnus [on Frederick Hirsch - due 2011-01-25].
http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0032.html
<Gerald-E> ScribeNick: Gerald-E
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0032.html
<fjh> proposed RESOLUTION: Remove CURIES from XML Signature 2.0 QNameAware description, add note that they are not in scope since they have their own prefix binding mechanism.
<scantor> it's in C14N
fjh: TLR does not think we need them, and to remove them from QName description.
<scantor> I don't think we should say anything
<fjh> proposed RESOLUTION: remove CURIES reference from C14N2
RESOLUTION: remove CURIES reference from C14N2
<fjh> Make PositionAssertion verification mandatory if present.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0031.html
<fjh> "I would like to see the verification of <dsig:PositionAssertion> not optional, so if a <dsig:PositionAssertion> is present, it must be verified"
mjensen: without this there may be conditions where a signature may be valid or invalid
fjh: should we make this mandatory?
<fjh> should this be a SHOULD?
<fjh> scott notes that considerations might be appropriate for different assertions
<fjh> scott notes that need to be clear on application responsibility versus security layer responsibility
<fjh> for wrapping attacks
scott: it is a question if everything is manditory. XML wrapping attacks are the responsabiltiy of the application at this time.
... this changes that
pdatta: this should be optional.
<fjh> proposed RESOLUTION: Keep PositionAssertion optional, including verification of it
scott: this is reasonable to put in the standard it is an impovement to say to use an XPath in the selection
<fjh> scott agrees with last sentence of Henrich's email, but possibly with should
pdatta: we can not make this mandadory, but this lets people be extra careful.
scott: this should be in the spec, in the PositionAssertion definition,
Hal: the wording should not suggest that this is the only way to acheive protection against wrapping attacks.
<pdatta> there will be some implementations which will use IDs instead of XPaths, and for these implementations making a PositionAssertion as mandatory is not acceptable, because that would mean XPath is mandatory. And if that were true then the signer could have used IncludedXPath to begin with.
<fjh> hal notes application might have policy of ignoring anything that isn't signed etc
<scantor> ACTION: scantor to add wording about using IncludedXPath in favor of PositionAssertion [recorded in http://www.w3.org/2011/01/18-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-772 - Add wording about using IncludedXPath in favor of PositionAssertion [on Scott Cantor - due 2011-01-25].
<fjh> proposed RESOLUTION: Keep PositionAssertion optional, including verification of it
RESOLUTION: Keep PositionAssertion optional, including verification of it
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/0033.html
pdatta: this is in the latest draft
<fjh> ACTION-759?
<trackbot> ACTION-759 -- Pratik Datta to update requirements section of c14n2 with context/exclusive c14n requirement and description -- due 2011-01-11 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/759
<fjh> ACTION-763?
<trackbot> ACTION-763 -- Pratik Datta to review ISSUE-198 and where algorithm should be placed -- due 2011-01-11 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/763
<fjh> requirement for c14n2 for "simplicity", yet not clear that c14n2 simpler
pdatta: we can not say that c14 2.0 simpler.
scantor: leaving out XPath out makes it simpler, there is also simplicity of use, leaving out inclusive and exclusive
fjh: will progress 1.1 and 2.0 publications independently, though they may coincide..
... we will meet again next week, but not on the first of Feb.