Re: thoughts on X509Data

     I have some difficulty with this.  It is perfectly legitimate to
include more than one of the first triplet (Issuer+Serial, SKI, and
Subject).  In fact, it is both normal and advisable to include Subject and
SKI together.  X509CRL, when found by itself, does not specify a
certificate at all - so it makes sense with either Issuer+Serial or
Certificate.

          Tom Gindin

Kevin Regan <kevinr@valicert.com>@w3.org on 08/17/2000 04:28:01 PM

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


To:   John Boyer <jboyer@PureEdge.com>, XML DSig <w3c-ietf-xmldsig@w3.org>
cc:
Subject:  thoughts on X509Data





I want to share one final thought about X509Data.  When creating a KeyName,
KeyValue,
PGPData, MgmtData, RetrievalMethod, etc., we are referring to the data for
exactly one key.
However, with X509Data, we can refer to a multitude of keys/certificates.
I propose that
we bring X509Data (back) in line with all the other KeyInfo elements.  This
would make a lot
more sense for implementations that come across an X509Data element.  If we
restrict
each X509Data element to refer to only a single certificate, we offer
consistency with all
the other KeyInfo elements.  Without this, X509Data becomes somewhat of an
anomaly.

To this end, I propose the following:

<!ELEMENT X509Data ( (X509IssuerSerial?, X509SKI?, X509SubjectName?) |
X509Certificate | X509CRL )>

In other words, either one of X509IssuerSerial, X509SKI, or X509SubjectName
(in order), or one X509Certificate, or
one X509CRL.  This seems much more consistent with the other KeyInfo
elements and is much easier
to deal with conceptually, from an API standpoint, and for implementations.

--Kevin

Received on Thursday, 17 August 2000 19:26:52 UTC