RE: Questions/Comments for the current draft.

     Well, your intent is now clear.  Since this is a reasonable position,
I propose that a minor edit be made to section 4.4.4 to make it clear.
Before the sentence in 4.4.4 which begins "for example", we should add the
following sentence: A certificate is related to the signing key if it is
either a certificate for that key (normally an end entity certificate) or a
CA certificate in a certificate chain for one of the certificates for that
key, and multiple certificates (either EE or CA certificates) for a
specific key are permitted in a single KeyInfo element.  Further comments
below.

          Tom Gindin

Brian LaMacchia <bal@microsoft.com> on 07/11/2000 05:25:25 PM

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



> -----Original Message-----
> From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
> Sent: Tuesday, July 11, 2000 12:46 PM
> To: Brian LaMacchia
> Cc: 'Yoshiaki KAWATSURA'; w3c-ietf-xmldsig@w3.org
> Subject: 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.

It was my intent, and I certainly consider it legitimate, to include
multiple EE certificates with the same subject public key within X509Data,
along with any CA certificates that chain (directly or indirectly) off
those EE certificates.  The signer does not necessarily have any
information about the signature verifier's trust policies, so if multiple
certificates have
been issued for the same subject public key of the signer, any (or all) of
the issued EE certs might be relevant to the verifier.  (This also holds
true for CA certs, of course.)  In fact, it's easy to envision policies
where a verifier would accept a signature key only if it came with two or
more independent, validating cert chains.

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

It was the intent of the wording to 4.4.4 to include all certificates
related to the single key, including multiple EE certs.  This obviously
accords with the language in 4.4.

[TG] The wording was IMHO far from clear on this subject.  You have now
made your intent clear, and perhaps the wording can be clarified.

I do not see where you got the impression that "section 4.4.3 suggest that
Retrievalmethod be used *in preference to*" including an entire cert chain.
RetrievalMethod is simply a method for including an indirect pointer to
key-related information, and it provides a convenient mechanism for sharing
the same key-related information across multiple signatures.  The example
brought up in Victoria was of multiple signatures on a document that shared
the CA portions of one or more cert chains; instead of including the CA
certs once per signature they could be included once in the document and
referenced (via RetrievalMethod) in the KeyInfo elements of other
signatures.  Either method may be preferable, depending on the particular
scenario.

[TG] The example text in 4.4.3 reads like a recommendation of the technique
specified over the pre-existing one ("can reference this chain using a
single ... instead of including the entire chain ...").  I'm not saying
that it is wrong to make such a recommendation, either.

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

I think you read a little too much into my comments; I never explicitly
claimed SKI as a "valid global identifier", although it would certainly be
a valid one had PKIX specified exactly one appropriate method for
calculating SKI.  ("Appropriate" to me means SKI is the output of a
cryptographic hash function applied to the public key material, algorithm
ID and algorithm parameters.)  Nevertheless, SKI really is more useful than
I&SN for
discovering multiple certificates related to a single key, and I do expect
most PKIX implementations over time to generate "appropriate" SKIs.  (The
PGP community has been doing this for years, and the Keyserver network
supports KeyID-based searches.  It's really quite convenient.)

[TG] The two notes in RFC 2459 give output which can easily be
distinguished from each other, and thus the presence of the two of them
doesn't interfere with their being valid global ID's.  The problems with
such a usage are that the shorter method isn't adequate as a global ID and
that locally assigned SKI's are permitted.  Incidentally, for some
implementations, locally assigned SKI's are also convenient.  I would
expect most PKIX CA's to generate standard SKI's when the client does not
request one of his own, but I would not expect client SKI requests to
necessarily be disabled.

Received on Tuesday, 11 July 2000 18:19:48 UTC