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

[Russ Housley <housley@xxxxxxxxxx>]

Bob:

I must disaree.  PKIX cannot provide non-repudiation.  PKIX provides
necessary stuff, but the signing application must do other things that are
beyond the scope of PKIX.  S/MIME is one such application.

Russ

At 03:22 PM 3/11/98 -0700, Bob Jueneman wrote:
>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
>