RE: Questions/Comments for the current draft.

I am not sure I understand your comments.

I wanted to ask is how you can identify Public Key Certificate(PKC) to
verify the data signed by the corresponding private key.  It is hard
to identify PKC because KeyInfo element can include multiple
certificate.  For example, in PKCS#7, PKC, which is corresponding to
the private key which uses to be actually signed can be identified by
IssuerAndSerialNumber in SignerInfo.

We assume KeyInfo element includes the following certificate chain

    ROOT CA PKC
       |
     CA 1 PKC
       |
     CA 2 PKC
       |
     EE PKC

but the certificate which corresponds to the private key which to be actually signed
is CA1PKC (though this is unrealistic case.)

In this case, it is hard to find it.
Should We have some restrictions about this such as unrelevant
certificates MUST NOT be contained in KeyInfo?
What do you think?
----
Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp
 Business Solution Systems Development Division, Hitachi,Ltd.
Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721

>>>>> Tue, 11 Jul 2000 18:19:03 -0400,
	tgindin@us.ibm.com said:

>      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 Wednesday, 12 July 2000 06:51:19 UTC