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.  

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. 

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

					--bal

Received on Tuesday, 11 July 2000 17:26:46 UTC