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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Denis,

I agree with you.  (Maybe you would like a framed and notarized copy? :-)

Russ,

Before we relegate this problem to the S/MIME group, I'd like to
explore the possibility of a more general solution just a bit more. Although
it may be that the overhead, impact, yada, yada, of slightly revising the SIGNED
macro (or defining a new signature oid) will be too great for some
applications, the use of a specific signature algorithm OID would allow
that to be controlled.

Ideally, of course, the API calls wouldn't even change, except for the
OID definition. That may be a bit much to hope for, unless all of the
information is already in the certificate or can be obtained from the
operating system without an API call (e.g., the date/time).

But I would rather revise the one or two applications now to make use
of a common interface, rather than wait and have to revise applcations
one at a time later on.

Bob


>>> Denis Pinkas <Denis.Pinkas@bull.net> 03/11 3:04 PM >>>
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