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