RE: Last Call (CMP proof-of-possession)

["Arsenault, Al W." <awarsen@xxxxxxxxxxxxxx>]

Okay, as usual, the following are *personal opinions* only.

>----------
>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Thursday, October 09, 1997 3:22 PM
>To: 	Arsenault, Al W.; ietf-pkix@tandem.com
>Subject: 	Re: Last Call (CMP proof-of-possession)
>
>Here is the situation Id like PKIX-CMP to allow. Tell us perhaps
>if PKIX-CMP allows or disallows the scenario. My reading is that
>IETF is about to prevent conforming PKIX-CMP systems engaging in this
>issuing policy and scenario, by requiring the CA (B below)  to check PoP:-
>
>There are two CAs, A and B.
>
>A issues Peter a valid certificate, placing it in its repository. (Peter
>physically visits A's LRA to do PoP, as a pre-condition in A's policy)
>
>B may or may not have an agreement with A to offer commercial added-value
>to A's subscribers, as an option to them: extended warranties, offers of
>free things,
>customer support folk who speak Korean...not only English, etc.
>
>B access A's repository and resigns the cert etc, and sends it
>(via signed PKIX-CMP Cert messages) to Peter. Lets say Peter
>agreed to a "reasonable amount" of such solicitations, when subscribing
>to A.
>
>Peter acknowledges the "added-value" of the cert issuer B, and accepts
>the cert, replacing that of A for use in his favorite email client. Perhaps
>Peter pays
>some more money and also offers more authentication evidence under B's
>requirements
>for id confirmation.
>
>B notes Peter's accepting event and publishes the cert in B's repository.
>
>A maintains the original cert until it expires. Perhaps A and B share
>the money paid to B, or the legal obligations. Perhaps not.
>
>------
>
>Now, my reading of PKIX-3 (which I have read very carefully indeed) was
>that such a scenario is entirely within the applicability of its messeging
>protocol.
>My belief is that by requiring PoP in the manner being suggested,
>this scenario (particularly when A and B have no relationship) built
>using PKIX-3 CMP messages and using the operations described is no
>longer supported.


In my opinion, there are at least three cases:

(1) A and B have an agreement in which A agrees to act as an RA for B.

I believe this meets all the necessary requirements.  PoP was done (I'll
presume) by A before it issued the initial certificate.  Acting as an
RA, A vouches for this PoP to B.  PoP has been done.

(2) A and B do not have an RA agreement, but B's "acceptance" procedure
requires that PoP be done before B's certificate can be used.

This is also okay.  The certificate issued by B to Peter is not usable
until such time as PoP has been done by B.  Notwithstanding my own
personal views on "unsolicited business offer", this is still something
PKIX should allow.

(3) A and B do not have an RA agreement, and B's "acceptance" procedure
does not require PoP before Peter can use the cert issued by B.

This should not be supported.  B is supposed to be a "certification
authority", yet B is actually purporting to certify something about
which he knows nothing.  He does not have any reason to believe that the
public key he put in the certificate is actually Peter's public key -
and A will not likely defend B should the question go to court, since
there's no agreement.  

As the recipient of a message sent by Peter using the certificate from
B, quite frankly I'd like to know that there was no basis whatsoever for
B to have "certified" anything, so that I can properly reject the
transaction out of hand.


>> Al Arsenault
>>
>> - I speak only for myself; my opinions do not necessarily represent
>>those of my employer
>>>
>>>
>>
>
>