RE: Questions/Comments for the current draft.

     Comments below.  Kawatsura-san has brought up an important point.
While most KeyInfo's whose X509Data's refer to multiple certificates refer
to one EE certificate and CA certificates above it in a chain, it is not
clear whether or not it is legitimate to include multiple EE certificates
which have the same public key, potentially along with CA certificates in a
separate chain for each EE certificate.

          Tom Gindin

Brian LaMacchia <bal@microsoft.com>@w3.org on 07/11/2000 11:44:52 AM

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


To:   "'Yoshiaki KAWATSURA'" <kawatura@bisd.hitachi.co.jp>,
      w3c-ietf-xmldsig@w3.org
cc:
Subject:  RE: Questions/Comments for the current draft.



> -----Original Message-----
> From: Yoshiaki KAWATSURA [mailto:kawatura@bisd.hitachi.co.jp]
> Sent: Monday, June 26, 2000 2:20 AM
> To: w3c-ietf-xmldsig@w3.org
> Cc: kawatura@bisd.hitachi.co.jp
> Subject: Questions/Comments for the current draft.
>
>
> Hello,
> I have some questions/comments for the current draft.
>
> (1) For KeyInfo Element
> A combination of Issuer Name and Certificate Serial Number is used as
> the identifier for the actual public key to verify the signature in
> PKCS#7.  Additionally, a combination of issuer name, subject name and
> subject key identifier is also used (this is described in
> draft-ietf-pkix-technr-00.txt.)
>
> How does validation application identify "the" key information
> which has been used for signature, although KeyInfo can include
> many key (certificate) information?

I'm not sure I understand the question here.  Every sub-element within a
KeyInfo structure potentially provides information concerning the key pair
used to generate the signature.  Depending on what sort of information is
meaningful to the signature-verifying application each sub-element may or
may not convey something useful.  Once the correct key has been discovered
&
the mathematics of the signature verified, then again each sub-element may
convey trust-related information to the application.  Of course, the
application is free to ignore this information and use its own resources to
determine how much trust to put in the key pair and signature.

[Tom Gindin] IMO, if KeyInfo contains multiple certificates, all but one of
those certificates should be CA certificates of some type (self-signed,
cross, or hierarchical).  The wording of the current draft is a little
contradictory on this.  Section 4.4 states that "(m)ultiple declarations
within KeyInfo refer to the same key".  In contrast, section 4.4.3 suggests
that RetrievalMethod be used in preference to "including the entire chain
with a sequence of X509Certificate elements".  Then in section 4.4.4 the
existence of multiple certificates in X509Data elements is described as
"different certificates (related to that single key)".  My interpretation
of this is that there should be only reference to only one certificate in
X509Data certifying the key pair used to sign the document, with other
certificates being part of certificate chains.  Does anyone think that it
is proper to put multiple EE certificates with the same key into X509Data?

Within X509Data, there are three primary ways to look up related certs:
ds:X509IssuerSerial, X509SKI and X509SubjectName.  ds:X509IssuerSerial is
there mostly for legacy purposes (including PKCS#7); SKI is a much better
identifier of the key material.  A combination of ds:X509IssuerSerial and
X509SubjectName would give you the (issuer, subject, SKI) triple that Tom
uses in the technr-00 draft.  This combination is explicitly allowed within
a single X509Data element.

[Tom Gindin] SKI is only a valid global identifier of the key material if
it was assigned to a hash of the public key, especially using one of the
two notes to the SubjectKeyIdentifier extension in RFC 2459.  If it was
assigned as a monotonically increasing sequence number, or as a local
storage ID, it is not a global identifier by itself.  In fact, if you use
note 2 (which generates 64 bits of output, 4 of which are redundant), it's
barely adequate as a global ID since collisions will become likely as the
PKI grows.

                         --bal

Received on Tuesday, 11 July 2000 12:46:43 UTC