Denis,
I did a quick search for the offending statement in RFC 3280 as well as3280bis, but could not find it. Are you thinking of a statement inCMP or CRMF?
===========================================
Sorry. My mistake. It was RFC 4210 (CMP) that states :
"However, it is REQUIRED that CAs/RAs MUST enforce POP by some means because there are currently
many non-PKIX operational protocols in use (various electronic mail protocols are one example)
that do not explicitly check the binding between the end entity and the private key.
Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist,
and are ubiquitous, this binding can only be assumed to have been verified by the CA/RA."
Thus no "change" required in 3280bis, but only an addition.
Denis
===========================================
Thanks,
Tim
At 04:50 PM 10/26/2005 +0200, denis.pinkas@xxxxxxxx wrote:
Russ,
My previous reply wastoo concise.
YES, I am suportive ofpublicKeyValadation (0), but please also note as Security AreaDirector
that a change to 3280bis should also be done : POP should no more bemandated in any case.
Denis
Denis:
Are you speaking in support of the extension that I proposed?
Russ
At 09:11 AM 10/26/2005, denis.pinkas@xxxxxxxx wrote:
>Russ and Stefan,
>
>This is an interresting issue. Thanks for raising it.
>
>(text deleted)
>
>So since POP always MUST be performed by the CA there seems not tobe
>the need for diverse policies (POP and non POP).
>
>Once upon a time, in the early years of PKI, RFC 2459 stated that
>sentence that was blindly copied from document to document.
>
>In these early years, most (if not all) security protocols were
>badly designed and thus for them to remains secure
>the only way was to include the MUST condition.
>
>However since then, the earth has rotated and at least there now
>exists one case where POP is no more needed without any securitythreat.
>
>This case was introduced by S/MIME with the optionally signed
>attribute ESSCertID.
>
>It was then taken by ETSI with the mandatory ESSCetrtID (or iis
>equivalent that does not mandate the use of SHA-1).
>
>RFC 3126 specifies that format.
>
>Taking into consideration these facts, this means that there exists
>at least one case where POP does not need to be performedanymore.
>
>There still exists cases where it needs to be performed, in
>particular when the certificate is used for encryption purposes.
>
>I believe that POP is mandatory when the key is used for encryptionpurposes.
>
>I believe that POP is NOT REQUIRED when the key is used for non
>repudiation purposes (e.g. RFC 3126 is used).
>
>When the key is used for authentication purposes, then depending
>upon the characteristics of the protocol,
>it MAY be required or not. So in that case only, it would make sense
>to support the extension proposed by Russ.
>
>Denis
>
>=============================================================================
>
>Do you agree with these observations or have I missed something?
>
>
>Stefan Santesson
>Program Manager, Standards Liaison
>Windows Security
>
>
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx
>[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On Behalf Of Russ Housley
> > Sent: den 25 oktober 2005 23:04
> > To: ietf-pkix@xxxxxxx
> > Subject: Public key validation and Proof of possession
> >
> >
> > Dear PKIX WG:
> >
> > The draft NIST SP 800-56 defines the requirements for"Recipient
> > Assurance of Static Public Key Validity." See Section5.6.2.2, where
>it
> > says:
> >
> > The recipient of a static public key shall obtain assurance ofits
> > validity
> > in one or more of the following ways:
> >
> > 1. Recipient Full Validation - The recipient performs a
>successful
> > full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 2. TTP Full Validation - The recipient receives assurancethat
>a
> > trusted
> > third party (trusted by the recipient) has performed a
> > successful full
> > public key validation (see Sections 5.6.2.4 and 5.6.2.5).
> >
> > 3. TTP Generation - The recipient receives assurance thata
> > trusted third
> > party (trusted by the recipient) has ge nerated the
> > public/private key
> > pair in accordance with Section 5.6.1 and has provided the
> > key pair to
> > the owner.
> >
> > It seems to me that option 2 was include to allow a CA toperform the
> > public key validation once, and then any party that makes useof the
> > certificate need not do it again. From a systemperformance
> > perspective, this seems highly desirable.
> >
> > In some highly assured implementation environments, itseems
> > desirable for there to me an indication in the certificate thatthis
> > action was taken by the CA. One could determine whichcertification
> > policies require the CA to take this action, but that meansthat the
> > list of certification policies would be continually adjusted byan
> > administrator. I would prefer a non-critical extension thatdeclared
> > that this action was taken by the CA.
> >
> > The draft NIST SP 800-56, Section 5.6.3.2 discusses therequirement
> > for "Recipient Assurance of the Owner's Possession of aStatic
> > Private Key." That is, the topic we have been discussingfor years
> > on this list, calling it proof of possession. RFC 3647 includesa
> > place in the certification policy to discuss this topic. (RFC3647,
> > Section 3.2.1: Method to prove possession of private key.)
> >
> > Again, in some highly assured implementation environments, itseems
> > desirable for there to me an indication in the certificate thatproof
> > of possession was performed by the CA. I think it could be partof
> > the same non-critical extension proposed above.
> >
> > I therefore propose that the PKIX WG generate a standards-trackRFC
> > to define a certificate extension to provide these indications.I
> > propose a very simple syntax:
> >
> > id-pe-caChecks OBJECT IDENTIFIER ::= { id-pe <TBD> }
> >
> > CAChecks ::= BIT STRING {
> > publicKeyValadation (0),
> > proofOfPossession (1) }
> >
> > Do others think this is a useful extension?
> >
> > Russ
>