RE: Questions/Comments for the current draft.


Would it make sense to somehow delineate different chains within
the KeyInfo element? Rather than just having a hodgepodge of certificate
would it be possible to group them in something like a
element (in the correct order)?  As a user (and implementer) of XML
Signatures, it
would be great to have a well-defined way of representing the
certificates/keys/certificate chains that I would use to authenticate
the signature.
The KeyInfo field is very flexible, but maybe a little less flexibility
would go a
long way here... :-)

Kevin Regan

-----Original Message-----
From: []
Sent: Tuesday, July 11, 2000 3:19 PM
To: Brian LaMacchia
Cc: 'Yoshiaki KAWATSURA';
Subject: RE: Questions/Comments for the current draft.

     Well, your intent is now clear.  Since this is a reasonable
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
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
key, and multiple certificates (either EE or CA certificates) for a
specific key are permitted in a single KeyInfo element.  Further

          Tom Gindin

Brian LaMacchia <> on 07/11/2000 05:25:25 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   "'Yoshiaki KAWATSURA'" <>,
Subject:  RE: Questions/Comments for the current draft.

> -----Original Message-----
> From: []
> Sent: Tuesday, July 11, 2000 12:46 PM
> To: Brian LaMacchia
> Cc: 'Yoshiaki KAWATSURA';
> 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
> to one EE certificate and CA certificates above it in a chain, it is
> clear whether or not it is legitimate to include multiple EE
> which have the same public key, potentially along with CA certificates
> 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
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
certificates have
been issued for the same subject public key of the signer, any (or all)
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
more independent, validating cert chains.

> Brian LaMacchia <> on 07/11/2000 11:44:52 AM
> Sent by:
> To:   "'Yoshiaki KAWATSURA'" <>,
> cc:
> Subject:  RE: Questions/Comments for the current draft.
> > -----Original Message-----
> > From: Yoshiaki KAWATSURA []
> > Sent: Monday, June 26, 2000 2:20 AM
> > To:
> > Cc:
> > 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
> those certificates should be CA certificates of some type
> cross, or hierarchical).  The wording of the current draft is a little
> contradictory on this.  Section 4.4 states that "(m)ultiple
> within KeyInfo refer to the same key".  In contrast, section 4.4.3
> that RetrievalMethod be used in preference to "including the entire
> with a sequence of X509Certificate elements".  Then in section 4.4.4
> existence of multiple certificates in X509Data elements is described
> "different certificates (related to that single key)".  My
> of this is that there should be only reference to only one certificate
> X509Data certifying the key pair used to sign the document, with other
> certificates being part of certificate chains.  Does anyone think that
> is proper to put multiple EE certificates with the same key into

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
Retrievalmethod be used *in preference to*" including an entire cert
RetrievalMethod is simply a method for including an indirect pointer to
key-related information, and it provides a convenient mechanism for
the same key-related information across multiple signatures.  The
brought up in Victoria was of multiple signatures on a document that
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

[TG] The example text in 4.4.3 reads like a recommendation of the
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
> it was assigned to a hash of the public key, especially using one of
> two notes to the SubjectKeyIdentifier extension in RFC 2459.  If it
> 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
> note 2 (which generates 64 bits of output, 4 of which are redundant),
> barely adequate as a global ID since collisions will become likely as
> 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
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,
ID and algorithm parameters.)  Nevertheless, SKI really is more useful
I&SN for
discovering multiple certificates related to a single key, and I do
most PKIX implementations over time to generate "appropriate" SKIs.
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
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
request one of his own, but I would not expect client SKI requests to
necessarily be disabled.

Received on Tuesday, 11 July 2000 18:33:51 UTC