W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > June 2007

Draft minutes XMLSEC 2007-06-12

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 12 Jun 2007 19:57:00 +0200
To: public-xmlsec-maintwg@w3.org
Message-ID: <20070612175700.GA14812@raktajino.does-not-exist.org>

Draft minutes are here:


Text version attached.
Thomas Roessler, W3C  <tlr@w3.org>


                                   - DRAFT -

           XML Security Specifications Maintenance WG Conference Call

12 Jun 2007


   See also: [3]IRC log


          Frederick_Hirsch, +aaaa, Thomas, deastl, grw, sean, RobMiller,
          Hal_Lockhart, jcc, PHB, konrad, +??P8

          Frederick Hirsch

          Donald Eastlake


     * [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


   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:

   <fjh> pls review widget signing

   chair: Hal ageed to scribe on the 26th, still look for scribe to the

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,

   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


   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

   <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:

   chair: action items and workshop review completed

Decyrption transforms

   <klanz2> Action-43:

   chair: Have fixed for canonicalization 1.1, next step move to public

   <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


   <fjh> current proposal:

   <klanz2> ##1##

   chair: Konrad has put a proposal on the list which restored bullet

   chair: do we want to make this change? What we have no is not quite

   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

   <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]



   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

   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

   <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

   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

   <klanz2> > in the first sub point of the second bullet point.

   <klanz2> > This position is also supported by the examples given in

   <klanz2> >
   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

   <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

   deastl: I don't remember

   <klanz2> some evidence:

   <klanz2> [2] says: "The following example set contains test vectors for

   <klanz2> OPTIONAL DNAME encoding"

   <klanz2> [3] says: "

   <klanz2> * The |X509IssuerSerial| element, which contains an X.509

   <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

   <klanz2> distinguished name that SHOULD be compliant with RFC2253

   <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]

   <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

   <fjh> greg: cannot go beyond SHOULD with errata

   r: mistake is about not escaping leading white space?


   tlr: RFC 2253 says deal with UTF-8 by escaping some characters with
   ... 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

   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

   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

   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

   <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
   [NEW] ACTION: tlr to see if RFC4514 is consistent with dsig encoding
   rules [recorded in

   [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 $


   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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:42 UTC