- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 12 Jun 2007 19:57:00 +0200
- To: public-xmlsec-maintwg@w3.org
Draft minutes are here:
http://www.w3.org/2007/06/12-xmlsec-minutes
Text version attached.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
- DRAFT -
XML Security Specifications Maintenance WG Conference Call
12 Jun 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Frederick_Hirsch, +aaaa, Thomas, deastl, grw, sean, RobMiller,
Hal_Lockhart, jcc, PHB, konrad, +??P8
Regrets
Chair
Frederick Hirsch
Scribe
Donald Eastlake
Contents
* [4]Topics
1. [5]Administrative
2. [6]minutes from last time
3. [7]review of actions
4. [8]workshop
5. [9]action items (2)
6. [10]Decyrption transforms
7. [11]Distinguished Names
8. [12]Optionality of DNAME encoding rules
* [13]Summary of Action Items
__________________________________________________________________
Administrative
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:
[14]http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Jun/2
0014.html
<fjh> pls review widget signing
[15]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
017.html
chair: Hal ageed to scribe on the 26th, still look for scribe to the
19th
minutes from last time
<scribe> Chair: any comments?
<tlr> [16]http://www.w3.org/2007/06/05-xmlsec-minutes.html
<scribe> Chair: none, minutes approved
<tlr> yep
review of actions
<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>
[17]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
031.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
workshop
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
[18]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
action items (2)
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> [19]http://www.w3.org/mid/466E7D31.20700@iaik.tugraz.at
<klanz2>
Action-49:[20]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg
/2007Jun/0028.html
<klanz2> Action-49:
"[21]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/
0028.html"
chair: action items and workshop review completed
Decyrption transforms
<klanz2> Action-43:
[22]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
027.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
Distinguished Names
<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>
[23]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
016.html
<fjh> current proposal:
[24]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
004.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>
[25]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
004.html
<jcc>
[26]http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0
020.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> [27]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> >
[28]http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/024
6.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:"
Optionality of DNAME encoding rules
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> <[29]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> <[30]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]
[31]http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
<klanz2> [3] [32]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
[33]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.
Summary of Action Items
[NEW] ACTION: phb to create workshop logistics page [recorded in
[34]http://www.w3.org/2007/06/12-xmlsec-minutes.html#action01]
[NEW] ACTION: tlr to see if RFC4514 is consistent with dsig encoding
rules [recorded in
[35]http://www.w3.org/2007/06/12-xmlsec-minutes.html#action02]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [36]scribe.perl version 1.128
([37]CVS log)
$Date: 2007/06/12 17:56:08 $
__________________________________________________________________
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0025.html
3. http://www.w3.org/2007/06/12-xmlsec-irc
4. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#agenda
5. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item02
6. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item03
7. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item04
8. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item05
9. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item06
10. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item07
11. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item08
12. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#item09
13. file://localhost/home/roessler/W3C/WWW/2007/06/12-xmlsec-minutes.html#ActionSummary
14. http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Jun/20014.html
15. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0017.html
16. http://www.w3.org/2007/06/05-xmlsec-minutes.html
17. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0031.html
18. http://www.w3.org/2007/06/12-xmlsec-minutes.html#action01
19. http://www.w3.org/mid/466E7D31.20700@iaik.tugraz.at
20. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html
21. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html
22. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0027.html
23. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0016.html
24. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.htm
25. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.html
26. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0020.html
27. http://www.w3.org/2001/10/xmldsig-errata#E01
28. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0246.html
29. http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN%3E
30. http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN%3E
31. http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
32. http://www.w3.org/TR/xmldsig-core/#sec-X509Data
33. http://www.w3.org/2007/06/12-xmlsec-minutes.html#action02
34. http://www.w3.org/2007/06/12-xmlsec-minutes.html#action01
35. http://www.w3.org/2007/06/12-xmlsec-minutes.html#action02
36. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
37. http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 12 June 2007 17:57:09 UTC