Re: AW: Errors and Questions

I think there is a great deal of wisdom in this suggestion. It is not
necessary to have a pki in order to affix or verify a digital signature. By
subordinating x509 issues, the goal of technology neutrality is more closely
achieved by the XMLdsig draft.

----- Original Message -----
From: "Brian LaMacchia" <bal@microsoft.com>
To: <tgindin@us.ibm.com>; "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>
Sent: Friday, July 28, 2000 1:58 PM
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 Saturday, 29 July 2000 10:18:57 UTC