RE: Public key validation and Proof of possession

["Bob Bell \(rtbell\)" <rtbell@xxxxxxxxx>]

Denis -

 

I have a question. It would seem to me that for non-repudiation as with the other modes for the cert, without the POP step, there is no way to prove that I as the presenter of the Cert am truly entitled to claim that cert as mine. Since a cert is public information, available from multiple sources presumably, then anyone may acquire the cert. It is only by being able to prove that I have the private key through POP am I able to assert that the cert is in fact MY identity.

 

Am I missing something here?

 

Bob Bell

---

From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of denis.pinkas@xxxxxxxx
Sent: Wednesday, October 26, 2005 07:12
To: Stefan Santesson
Cc: Russ Housley; ietf-pkix@xxxxxxx
Subject: RE: Public key validation and Proof of possession

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 to be
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 security threat.

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 performed anymore.

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 encryption purposes.

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 Section 5.6.2.2, where
it
> says:
>
> The recipient of a static public key shall obtain assurance of its
> 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 assurance that
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 that a
> 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 to perform the
> public key validation once, and then any party that makes use of the
> certificate need not do it again. From a system performance
> perspective, this seems highly desirable.
>
> In some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that this
> action was taken by the CA. One could determine which certification
> policies require the CA to take this action, but that means that the
> list of certification policies would be continually adjusted by an
> administrator. I would prefer a non-critical extension that declared
> that this action was taken by the CA.
>
> The draft NIST SP 800-56, Section 5.6.3.2 discusses the requirement
> for "Recipient Assurance of the Owner's Possession of a Static
> Private Key." That is, the topic we have been discussing for years
> on this list, calling it proof of possession. RFC 3647 includes a
> place in the certification policy to discuss this topic. (RFC 3647,
> Section 3.2.1: Method to prove possession of private key.)
>
> Again, in some highly assured implementation environments, it seems
> desirable for there to me an indication in the certificate that proof
> of possession was performed by the CA. I think it could be part of
> the same non-critical extension proposed above.
>
> I therefore propose that the PKIX WG generate a standards-track RFC
> 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