RE: AW: Errors and Questions

     If the single-certificate restriction is accompanied by a
recommendation that a chain be represented by multiple single-certificate
X509Data's, and that multiple X509Data's within a KeyInfo be interpreted as
a set of chains, I withdraw my objection.  We had at least one earlier
discussion on X509 chains, and little of it made it into the latest draft.
In particular, the "different certificates (related to that single key)"
wording in 4.4.4 has not been clarified at all, and no reference to chains
occurs within that section.  Part of the problem with this is that it is
difficult to make an example which represents a chain in a way that is
understandable from the example.  I attach a reasonable try below, in which
all certificates other than the root include an (Issuer, Serial) pair and
all of them include a subject name.
     I also think that trying to create an XML-native representation of
X.509 certificates is likely to result in a representation whose signature
cannot be verified (not that a native XML certificate could not be
verified, but the transformation from ASN.1 would not necessarily be
reversible).
     RFC 2253 does not require the escaping of non-ASCII characters, in any
case.  If the few places where we use it, we would probably be best off
saying that non-ASCII characters should not be escaped.  Also, if you want
an XML-native representation of DN's, you MUST include an RDN level for
them to be convertible to RFC 2253 or ASN.1 - I can't tell from the example
whether <E> and <CN> are on the same level or not.

          Tom Gindin

  <X509Data>
            <X509IssuerSerial>
              <X509IssuerName>C=US, O=XML Examples Highly
Limited</X509IssuerName>
              <X509SerialNumber>12345678</X509SerialNumber>
            </X509IssuerSerial>
     <X509SubjectName>C=US, O=W3C, CN=XML Author</X509SubjectName>
            <X509SKI>Q1d97bD7aBA=</X509SKI>
          </X509Data>
          <X509Data>
            <X509SubjectName>C=US, O=XML Examples Highly
Limited</X509SubjectName>
            <X509IssuerSerial>
              <X509IssuerName>C=US, O=Real Live Higher CA</X509IssuerName>
              <X509SerialNumber>123456789</X509SerialNumber>
            </X509IssuerSerial>
          </X509Data>
          <X509Data>
            <X509SubjectName>C=US, O=Real Live Higher CA</X509SubjectName>
            <X509SKI>Q5dEXbD7aBA=</X509SKI>
          </X509Data>

Brian LaMacchia <bal@microsoft.com> on 07/28/2000 04:58:01 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Gregor Karlinger
      <gregor.karlinger@iaik.at>
cc:   Barb Fox <bfox@exchange.microsoft.com>, "Joseph M. Reagle Jr."
      <reagle@w3.org>, XML <w3c-ietf-xmldsig@w3.org>
Subject:  RE: AW: Errors and Questions



The fact that we are continuing to have problems settling on a schema for
X509Data this late in the game causes me to reconsider including X509Data
in
the core DSIG specification.  In fact, the more I think about it, the more
I
am coming to believe that we should remove X509Data from XMLDSIG and move
it
to a parallel, subordinate draft that would be generated by or
inconjunction
with the PKIX/X.509 community.  I say this because X509Data is not core to
XMLDSIG and I fear it will hold up progression of the standard.  If other
folks agree we should discuss this in Pittsburgh next week.

Here's my thinking on the matter:

1) Based on our experience so far, it's clear that trying to create an
XML-based representation for X.509/PKIX Part 1 data is a non-trivial task.
The problem Kent raised with RFC 2253 encoding of a DN is one example.  To
quote from his previous mail:

>RFC 2253 has an original method to escape non-ASCII octets.  It
>is strange for XML applications.  An example in RFC 2253,
>    <X509SubjectName>SN=Lu\C4\8Di\C4\87</X509SubjectName>
>is not suitable for XML.  I think XML applications prefer
>following form:
>    <X509SubjectName>SN=Lu&#x10d;i&#x107;</X509SubjectName>

He's absolutely right, RFC2253 isn't XML-friendly.  (How could it be when
it
predated XML?)  While we could backpatch 2253 with something like his
proposal, it seems to me that if we're going to define an XML-friendly way
of representing a DN then we really ought to do it following the tenets of
XML.  What I mean is that since a DN is a structured object, its XML
representation should reflect that structure, too.  Using the Subject Name
from Kevin Regan's last S/MIME message to the list as an example, I could
see something like this for X509SubjectName:

<X509SubjectName>
     <E>kevinr@valicert.com</E>
     <CN>Kevin Regan</CN>
     <OU>Digital ID Class 1 - Microsoft Full Service</OU>
     <OU>Persona Not Validated</OU>
     <OU>www.verisign.com/repository/RPA Incorp. by
Ref.,LIAB.LTD(c)98</OU>
     <OU>VeriSign Trust Network</OU>
     <O>VeriSign, Inc.</O>
</X509SubjectName>

(There'd have to be an X.509/PKIX namespace for these elements, of course,
but I've elided that.)  We'd use standard UTF-8 encoding rules for
non-ASCII
octets, so Kent's example would become:
     <X509SubjectName><SN>Lu&#x10d;i&#x107;</SN></X509SubjectName>

Obviously, this is just the tip of the iceberg when it comes to X.509/PKIX
Part 1.  There are many portions of that specification, and the related
specifications that could have a lightweight XML-based representation.  (I
don't think, though, that the XML representation should necessarily be
derived from the ASN.1 representation; seems to me a better job could be
done looking at the actual data structures.)

2) X509Data is not core to XMLDSIG.  This is clear from RFC 2807 (the
requirements doc), esp. 2.3.2 and 2.5.  We've said that trust semantics are
specifically outside the standard, and support for X509Data is already
OPTIONAL in XMLDSIG.  The more we dig into X509Data the more complexity we
find.  Some folks want to communicate entire chains fo certs...how should
we
represent chains?  It's not as easy as just embedding all the certs,
because
you might want to reference published certificates for part of the chain to
keep message size down.  How should complex cross-certification webs be
represented?   Is it even the job of X509Data to communicate ordering
information, or is it just a bag of certs?

3) X509Data and the "everyting in a KeyInfo element relates to a single
key"
dictum.  It's clear that we still can't decide what it means for X509Data
that "[m]ultiple declarations within KeyInfo refer to the same key."
Follwing that convention we have chains represented as follows:

<KeyInfo>
  <X509Data><X509Certificate>...cert A data...</X509Certificate></X509Data>
  <X509Data><X509Certificate>...cert B data...</X509Certificate></X509Data>
  <X509Data><X509Certificate>...cert C data...</X509Certificate></X509Data>
  <X509Data><X509Certificate>...cert D data...</X509Certificate></X509Data>
</KeyInfo>

Where A, B, C and D all "relate" to the same key, e.g. part of a chain.
Gregor, I believe you and Tom may have misread/misinterpreted Barb's
previous statement.  "One per clause" means you can have exactly one
X509Certificate element per X509Data.  A chain would be represented as
multiple X509Datas within a single KeyInfo, as in my example.  If this
isn't
satisfactory, perhaps the WG needs to revisit the decision from Victoria,
but in any case the continuing confusion/discussion is further evidence
that
X509Data isn't ready for prime time.

4) PKI data neutrality.  Finally, it seems weird to me that this working
group is spending so much of its limited resources arguing over one
particular type of trust-related data for keys.  We agreed to give the
other
IETF-recognized trust semantics (PGP and SPKI) a slot in the standard where
they could plug in their own sub-elements.  With PGP we went slightly
further and put out a proposed set of PGPData elements, but I have no idea
if that's really going to be sufficient for their needs.  SPKI we've
explicitly said will be defined by the SPKI WG.  Seems to me that we should
deal with X509Data on equal terms.

So, in summary, I propose that we remove the detailed element schema from
sections 4.4.4-4.4.7 (X509Data, PGPData, SPKIData and MgmtData) and spin
thouse sections out to subordinate drafts.  We can reserve the tags
"X509Data", "PGPData", "SPKIData" and "MgmtData" within the XMLDSIG
namespace, and work on a spec for X509Data can happen in parallel with the
finishing up XMLDSIG starting with what we currently have in 4.4.4 as a
strawman.  X509Data is not core to the standard nor many important
scenarios
(certainly I have scenarios that don't require X509Data), so this seems the
best way to allow further work on this particular component to happen
without holding up the entire standard.

                         --bal


-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Friday, July 28, 2000 11:55 AM
To: Gregor Karlinger
Cc: Barb Fox; Joseph M. Reagle Jr.; XML; Brian LaMacchia
Subject: Re: AW: Errors and Questions


     I agree with you.  I don't see why we should shift from having lots of
certificates allowed, with no guaranteed relationship between them, to
having only the EE certificate allowed and not allowing chains.  It makes
more sense, IMO, to set requirements on which certificates are allowed
along the lines of some earlier suggestions - for example, allowing only
one EE certificate and requiring that all other certificates be part of a
certification chain for that one.  We could even require that there be only
one chain and that the certificates appear in leaf-first order - it would
still be better than just a leaf and it would not be very hard to
implement.

          Tom Gindin

"Gregor Karlinger" <gregor.karlinger@iaik.at>@w3.org on 07/27/2000 03:54:06
AM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   "Gregor Karlinger" <gregor.karlinger@iaik.at>, "Barb Fox"
      <bfox@Exchange.Microsoft.com>, "Joseph M. Reagle Jr." <reagle@w3.org>
cc:   "XML" <w3c-ietf-xmldsig@w3.org>, "Brian LaMacchia"
      <bal@microsoft.com>
Subject:  AW: Errors and Questions




Sorry, I hit the  wrong key on my keyboard, and the message was gone ...

Hi Barb,



 > [GK20]Only a single certificate possible  here?  [Barb]  Yes. One per
clause.


Please see my comment on [GK20] in my  previous message:

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0176.html

Regards,  Gregor
---------------------------------------------------------------
Gregor  Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316  873 5541
Institute for Applied Information Processing and  Communications
Austria
---------------------------------------------------------------

Received on Friday, 28 July 2000 18:11:15 UTC