W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

RE: Questions/Comments for the current draft.

From: <tgindin@us.ibm.com>
Date: Wed, 12 Jul 2000 12:56:12 -0400
To: Yoshiaki KAWATSURA <kawatura@bisd.hitachi.co.jp>
cc: bal@microsoft.com, w3c-ietf-xmldsig@w3.org, kawatura@bisd.hitachi.co.jp
Message-ID: <8525691A.005D0A53.00@D51MTA04.pok.ibm.com>
     My proposal was that certificates be permitted in KeyInfo only if they
were certificates for the signing key or members of a chain FOR that
certificate.  A chain for a CA certificate extends upwards from that CA
certificate, but not downwards - it's not the same thing  as a chain
containing that CA certificate.    Thus if a CA is permitted to sign an XML
document the set of certificates for that document may not contain any EE
certificates.  Do we need to add that if a CA signed the document, KeyInfo
may not contain any certificates issued by that CA?

          Tom Gindin


Yoshiaki KAWATSURA <kawatura@bisd.hitachi.co.jp>@w3.org on 07/12/2000
06:50:09 AM

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


To:   Tom Gindin/Watson/IBM@IBMUS
cc:   bal@microsoft.com, w3c-ietf-xmldsig@w3.org,
      kawatura@bisd.hitachi.co.jp
Subject:  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.)

[Tom Gindin] This is a very unrealistic case.  If the KeyInfo element
includes that certificate chain the document MUST have been signed by EE
PKC.

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.
(snip)
Received on Wednesday, 12 July 2000 12:56:31 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:10 GMT