Re: [IETF-PKIX] Multiple certificates for same key?

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Stephen,

As Russ said, this discussion also relates to the CMS document from the
smime wg and we should schedule a time slot in the pkix wg to talk about
it at the LA meeting.

In addition I would like to make a few comments on your two E-mails from
yesterday.

> Bob,
>
> I feel that the discussion of "which cert goes with this signature" is
> overblown.  I would argue that a relying party needs to acquire a cert that
> is valid and that contains a public key that validates the signature of the
> signed data.

This is the wrong way. The signer has to indicate which certificate must
be used. The verifier should have no free choice.

> If there is a only ine cert with a key that conforms to these
> requirements, we're done.

No. I would not like to re-open the POP discussion ... but if the
certificate identifier of the signer is part of the signed stuff, then
we can do "real-time" POP.

> if there's more than one, then the relying party
> has been given the opportunity to choose whichever one he wants. Many
> applications I know of send the end user cert as part of a transaction,
> messages, or session establishment protocol.

The basic question is whether the end user cert is signed or not.
Currently, it is not signed and this is the problem.

> Thus the relying party is
> saved the trouble of having to guess, and ambuigity is avoided.  When
> non-repudiation is an issue, then it is important to understand the
> implications of multuiple certification and users and CAs should behave
> accordingly.  However, if they choose poorly and create opportunities for
> abmiguity and possible deception, I'd back the relying party if he can
> produce a valid cert that is plausibly associated with the user and which
> works from a signature validation perspective.
>
> Steve

Second E-mail:

(... stuff deleted ...)

> Thus, I am not persuaded that we need to preclude multiple certification of
> a public key in PKIX, but I am in favor of including a brief warning about
> the possible pitfalls of this practice, and a suggestion that this practice
> be avoided for end user certs in most circumstances.

I do not think this is the right way to present the problem. You seem to
assume that the single problem has to do with the same user with two
certificates that contain the same public key. As indicated above, in
addition, we need to consider two different users each one with a
certificate that contains the same public key (the POP problem).

The recommendation should be, for the non-repudiation case, to make sure
that the signature at least includes the identifier of the certificate
(or the certificate itself). It might also include a certification path
(ie. a sequence of certificate identifiers).

Denis

--
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas@bull.net
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21