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

["Peter Williams" <peter@xxxxxxxxxxxx>]

1. As agreed, and previously argued, there should be
no mandatory status for POP. The disadvantages
outweigh the advanages.

2. Those that are at final call (!) seeking to change
previous agreements should at least have
the decency to state the pro and con
arguments previously declared, if
they wish to have the "court change the
decision on appeal."

------


Should a CA wish to take a cert from the VeriSign
directory and reissue it to Fred, and send
Fred an email saying - replace your VeriSign
low-assurance $1000 cert with this cert with $10000
protection plan warranties, there should be nothing
***in PKIX** which prevents this commercial practice. It
is not for some IETF techie  types to set/limit business rules
or limit the scope of available policies through rigged
conformance rules.

Should VeriSign decide to upgrade its class 1 protections
"free" to Class 2 protections (having used some out of band means
to improve the user authentication an) it may invite its subscribers to
replace its OWN certs by sending them a (n invitation to
downloada ) replacement cert.

This is known as unsolicited cert issuance. PKIX must
not interfere with( commercial) use of such practices.
Safeguards on approprate and safe use of such
may be built into policy, versus technololgy, where
it belongs.

Of course a reputable CA will not issue *valid* certs of
this form, as validity of the unsolicited cert requires
that the user accept the invitation/cert, and the CA
maintain records that the "accepting event" took place.
Publication of the cert in a repository does not
take place in accreditable ABA DSG conforming
CA until the cert is valid. Noone can rely
on a cert which has yet to be published in the issuing
repository, note, in such policy control regimes.

Finally, note that this situation is more readily understandabe
if one considers smartcards. The banks send the replacement
smartcard (with centrally generated RSA key and signed cert) without
user request. The user and obligated party makes **NO** POP
prioir to cert issuance, though s/he does essentially
attest to POP conditions/assurances during acceptance of the the card, by
use or (in
some banks first contact procedures) activation of the card
through a required phone call etc.

I suspect this is what you Denis are getting at, and as always
I would agree with such perpectives based on the reality of
commercial vs merely military key management designs.


-----Original Message-----
From: Denis Pinkas <D.Pinkas@frcl.bull.fr>
To: IETF-PXIX <ietf-pkix@tandem.com>
Date: Wednesday, October 08, 1997 12:56 AM
Subject: Re: Last Call (CMP proof-of-possession)


>David, Tom , Bob, and all others ...
>
>Since I have been involved in the thread along PoP, here is my position.
>
>The text in section 2.3 currently says :
>
>" In order to prevent certain attacks and to allow a CA/RA to properly
>check the validity of the binding between an end entity and a key pair,
>the PKI management operations specified here make it possible for an end
>entity to prove that it has possession of (i.e., is able to use) the
>private key corresponding to the public key for which a certificate is
>requested.  A given CA/RA is free to choose whether or not to enforce
>POP in its certification exchanges (i.e., this may be a policy issue).
>However, it is STRONGLY RECOMMENDED that CAs/RAs enforce POP because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>I have no problem to change in the last sentence "STRONGLY RECOMMENDED"
>by "REQUIRED" provided that we say that this must be done by whatever
>means. In particular, when the key pair is generated by the CA, PoP is
>not required in the certification exchanges.
>
>So I would propose to reformulate that last sentence along something
>like the following:
>
>" However, it is REQUIRED that CAs/RAs verify POP by whatever means
>(i.e. using certification exchanges and/or procedural means) because
>there are currently many non-PKIX operational protocols in use (various
>electronic mail protocols are one example) which do not explicitly check
>the binding between the end entity and the private key."
>
>Denis
>
>--
>
>      Denis Pinkas     Bull S.A.         E-mail : D.Pinkas@frcl.bull.fr
>      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
>