See also: IRC log
chair: looking for scribes for future calls
chair: request for eview by another W3C group to review material, see link in agenda
<fjh> 008 plenary: http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Jun/20014.html
<fjh> pls review widget signing http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0017.html
chair: Hal ageed to scribe on the 26th, still look for scribe to the 19th
<scribe> Chair: any comments?
<tlr> http://www.w3.org/2007/06/05-xmlsec-minutes.html
<scribe> Chair: none, minutes approved
<tlr> yep
<tlr> ACTION-26 continued
chair: Action 26 - open
chair: action 35 open
<tlr> ACTION-36 continued
chair: action 36 to be reviewed by Juan Carlos - open
chair: action 37: to be revied by shaun open
chair: 41 review implementation, not captured in previous minutes, closed
chair: 42 Juan Crlos producing an example. done,
<klanz2> calling in
<tlr> konrad is not yet on the phone?
<klanz2> finished, mail to the list first
chair: 43 Conrad to produce examples, done??
<tlr> konrad, how about joining?
chair: leave 43 open to be conservative
chair: 44 closed, update the draft
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0031.html
chair: 45, done
chair: 46, done
chair: 47, decryption update draft, done
chair: 48, proposal to resolve issue
<klanz2> got kicked out
jcc: 48 still open
tlr: Action 39 shows open, would like to close it as done
chair: OK, close 39
chair: if/when Konrad come back talk about 49, 43
chair: Have revised CFP. Ready for release?
tlr: Have already submittted to W3C mgmt for approval
chair: what next
tlr: next, have set up mailing list to receive
position papers
... hope can announce tomorrow morning so we can start recruiting
... then get nervous because people ususally submit at deadline
chiar: sticking with 25/26 September dates, hosted at Verisgin?
tlr: Yes, hosting confirmed.
chair: didn't change due to short timeline, etc.
chair: Phil, give him action to create logistics page?
<PHB> sorry, got asked question
tlr: will need logistics page with hotels, etc.
Generally detailed logistics page only available to registrants
... happy to make an Action or just trust PHB to handle it
<fjh> ACTION: phb to create workshop logistics page [recorded in http://www.w3.org/2007/06/12-xmlsec-minutes.html#action01]
<trackbot-ng> Created ACTION-50 - Create workshop logistics page [on Phillip Hallam-Baker - due 2007-06-19].
tlr: By mid-
... by mi-July is fine
... Critical for people to do outreach of CFP
chair: Konrad, status of Action 43?
Konrad: should be closed. Original breakage example has been clarified
<tlr> ACTION-43 closed
<trackbot-ng> Sorry... I don't know how to close ACTION yet
Konrad: discharged on original brakage issue
chair: Action 49 Konrad?
Konrad: That one is also completed. Examples sent to list today.
<tlr> ACTION-49 closed
<trackbot-ng> Sorry... I don't know how to close ACTION yet
<tlr> http://www.w3.org/mid/466E7D31.20700@iaik.tugraz.at
<klanz2> Action-49:http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html
<klanz2> Action-49: "http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html"
chair: action items and workshop review completed
<klanz2> Action-43: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0027.html
chair: Have fixed for canonicalization 1.1, next step move to public review
<tlr> s/Decyprtion/Decryption/
chair: don't think people have looked at it, no reason not to give people another week to review
chair: OK, that plan accepted
<fjh> "compliant with RFC2253" or "compliant with the DNAME processing rules at end of section"
chair: We change the bullet list (agenda 6a) ...current editor's draft incorrect
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0016.html
<fjh> current proposal: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.htm
<klanz2> ##1##
chair: Konrad has put a proposal on the list which restored bullet items
chair: do we want to make this change? What we have no is not quite right
chair: Are we ok with Konrad's change? Should we post it to chat?
<klanz2> ##1##
<klanz2> As I wrote in [4] already
<klanz2> The text says:
<klanz2> "At least one element, from the following ... "
<klanz2> So the bullet points will still have to enumerate the the choice of
<klanz2> elements within the content of |X509Data| which is not the case in the
<klanz2> current red line document ... and will need to be changed to something like the following:
<klanz2> [4]:
<klanz2> > * The |X509IssuerSerial| element, which contains an X.509
<klanz2> > issuer distinguished name/serial number pair. The distinguished
<klanz2> > name SHOULD be compliant with the DNAME
<klanz2> > encoding rules at the end of this section and the serial
<klanz2> > number is represented as a decimal integer,
<klanz2> > * The |X509SubjectName| element, which contains an X.509
<klanz2> > subject distinguished name that SHOULD be compliant with the
<klanz2> > DNAME encoding rules at the end of this section,
<klanz2> [4]
<klanz2> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.html
<jcc> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0020.html
jcc: I send some comments a few days ago
... First bullet is OK
<jcc> The
<jcc> >> distinguished
<jcc> >> name SHOULD be compliant with the DNAME
<jcc> >> encoding rules at the end of this section and the serial
<jcc> >> number is represented as a decimal integer,
jcc: "and number is reperested by a decimal integer" is not necssary as schema says that
<klanz2> I'm not strong about this ...
Konrad: Don't see harm in having this in both the text and schema
tlr: we are dealing with Erratum 1
<fjh> E01 2002-01-28 (Editorial):
<klanz2> N.B.: the bullet points will still have to enumerate the the choice of
<klanz2> elements within the content of |X509Data|
<fjh> http://www.w3.org/2001/10/xmldsig-errata#E01
tlr: DNAME rules, which take precidence, are subtly different from RFC 2253... what does this have to do with schema values?
chair: are we going beyond the Errata
chair: any other opinions, would like to resolve
<Sean> I agree with jcc, no need to mention serial number in first bullet.
chair: maybe way forward is to remove that
<klanz2> s/and the serial number is represented as a decimal integer//
tlr: can Konrad type updated text
<klanz2> [4]:
<klanz2> > * The |X509IssuerSerial| element, which contains an X.509
<klanz2> > issuer distinguished name/serial number pair. The distinguished
<klanz2> > name SHOULD be compliant with the DNAME
<klanz2> > encoding rules at the end of this section,
<klanz2> > * The |X509SubjectName| element, which contains an X.509
<klanz2> > subject distinguished name that SHOULD be compliant with the
<klanz2> > DNAME encoding rules at the end of this section,
chair: proposal becomes what the Errata tried to say originally
Konrad: No, actually we removed the first two bullet points and merged..
fjh: reads awkwardly
chair: OK with approving
<klanz2> +1 to fjh
<tlr> +1
<jcc> +jcc
chair: OK, get red line fixed and then consider approving whole section
<tlr> phill, did the connection drop suddenly?
chair: any objection to tentative approve understanding we will re-reveiw whole section
<PHB> No, I just moved to my upstairs office
(no ojbections)
<tlr> ah, good
<fjh> RESOLUTION: Adopt change as noted above to 4.4.4 first 2 bullets, then review 4.4.4 as a whole later
<klanz2> ##2##
<klanz2> I also believe we agree on the following mentioned in [5] about the
<klanz2> DNAME escaping rules at the end of the section:
<klanz2> > I would assume that leading spaces have been forgotten to be mentioned
<klanz2> > in the first sub point of the second bullet point.
<klanz2> > This position is also supported by the examples given in
<klanz2> > http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0246.html .
<fjh> p
<fjh> original was:
<fjh> "Also, strings in DNames (X509IssuerSerial,X509SubjectName, and
<fjh> KeyName if approriate) should be encoded as follows:"
<fjh> now in red-line:
<fjh> "DNames (X509IssuerSerial, X509SubjectName, and KeyName if
<fjh> appropriate) should be encoded in accordance with RFC2253 [LDAP-DN]
<fjh> except for the encoding of string values within a DName:"
chair: Konrad said it should be optional
chair: Do we agree, should we captialize SHOULD?
konrad: I had a closer look at postings to list of test cases. Speaks about DNAME encloding rules in such a way to imply it should be optional
deastl: I don't remember
<klanz2> some evidence:
<klanz2> [2] says: "The following example set contains test vectors for the
<klanz2> OPTIONAL DNAME encoding"
<klanz2> [3] says: "
<klanz2> * The |X509IssuerSerial| element, which contains an X.509 issuer
<klanz2> distinguished name/serial number pair that SHOULD be compliant
<klanz2> with RFC2253 [LDAP-DN
<klanz2> <http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN>],
<klanz2> * The |X509SubjectName| element, which contains an X.509 subject
<klanz2> distinguished name that SHOULD be compliant with RFC2253 [LDAP-DN
<klanz2> <http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN>],
<klanz2> "
<klanz2> [3] only says: "... should be encoded ... " where should is written in
<klanz2> small capitalization to the additional rules
chair: what does optionality mean for interoperability...?
<klanz2> I hence conclude the only normative statement in the original text is
<klanz2> that "distinguished names SHOULD be compliant with RFC2253".
<klanz2> [2] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
<klanz2> [3] http://www.w3.org/TR/xmldsig-core/#sec-X509Data
<klanz2> +1 to sean
should stry to stay within RFC 2253
Greg: doesn't seem like we can make a statement any stronger than should
<fjh> greg: cannot go beyond SHOULD with errata
r: mistake is about not escaping leading white space?
right
tlr: RFC 2253 says deal with UTF-8 by escaping
some characters with backslash
... is an implementation that uses \20 for space compliant or marginal?
... probably any reasonable implementation will understandt \20
Konrad: RFC 2253 only talks about he first and
last white space if any in a string, interior space can be escaped as \20
... some implementations might work but, strictly speaking, it does not
comply
chair: Do we agree that we can't go beyond "should" because we are doing Errata
<klanz2> Additionally some text like the following might do the trick for support
<klanz2> legacy signatures:
<klanz2> > For legacy support please note, that applications receiving signatures containing DNAMES having AttributeValues terminated by "\20"
<klanz2> > are RECOMMENDED to treat an "\20" escaped character at the end of an AttributeValue as if they were normal escaped space characters "\ " conformant to section 2.4 of RFC 2253. Do not convert "\20" to "\ " if the DNAME in question is signed.
Is it fair to current implementations to change the rules, even to a should
tlr: This is murky territory. Dealing with RFC 2253 which isn't that clear and interacting with other specs...
<klanz2> -1 to tlr
tlr: suggest sticking to current Errata. Before
resolving this Errata, someone whould construct a number of simple test cases
and try them on existing implementations.
... The best we can do is to try to figure out how people have interpreeted
the spec
... Have specific rule on the leading/traing white space seems too deep in
details...
Konrad: I disagree. We can do it better and be
backward compatible. Collateral damage will be essentially null.
... leading/traiing white space should almost never occur in certificates...
but should allow old practice
fjh: heard two things: red-line has change
based on Errata, uses lower case should. That does not seem controversial.
... But Konrad is suggesting enhacing with further text. Is that right?
tlr: the one normativity change we are making
is to item 1 where we are saying "SHOULD" be compatible to DNAME encoding
rules
... No longer making only informational change
Konrad: we are fixing an internal contradicition. It used to say should follow RFC 2253 but then gave slightly different rules...
tlr: Can read RFC 2253 to give format and rules
for generating that format. Rules are partially optional.
... xmlsig rules can be interpreted in a way consisten with normative rules
in RFC 2253 in such a way as to be not contradictory
... Disagree with Konrad's statement that there is a contradiction
Konrad: can give contractory examples
tlr: Not clear to me...
chair: need action(s) to clear this up. tlr has mentioned examples.
tlr: missing converting back rules
chair: tlr, can you put stuff on list to explain
chair: can anyone else on call help?
chair: we need more infor. Can't go forward otherwise
chair: Best thing for Thomas to put a message on the list...
chair: People on call should look at agenda, at other DNAME items, so we can get it right for the next call
chair: anything we can do on the list would help
chair: I'll try to speed up the Action item portion of calls.
chair: anyting else for remaining minute of call?
chair: Konrad, tlr, ..., any furhter suggestion for how to make progress?
Konrad: The suggestion should affect only future coreated signtures, like the changes we made re Canonicalization 1.1...
<klanz2> I 'll have to go now
<klanz2> +1 to tlr
<klanz2> I'll be on the list
tlr: One more thing: dealing with references to an obsoleded RFC. I'm checking the new replacemented to see if it is relevant.
<fjh> ACTION: tlr to see if RFC4514 is consistent with dsig encoding rules [recorded in http://www.w3.org/2007/06/12-xmlsec-minutes.html#action02]
<trackbot-ng> Created ACTION-51 - See if RFC4514 is consistent with dsig encoding rules [on Thomas Roessler - due 2007-06-19].
<tlr> and, indeed, it is!
chair: ajourn
<fjh> Thank you Donald for scribing.