RE: Public key validation and Proof of possession

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Russ,

I'm not sure whether this is useful or not.
I have some questions though.

On public key validation (arithmetic properties):
It seems to me that the key validation tests specified in 5.6.2.4 and
5.6.2.5 are rather trivial to do locally ( 2=<y=<p-2 and y^q=1(mod p)
for FFC), at least compared to the cost of using this key for anything
useful. I wonder if the cost of making this test isn't actually lower
than parsing the certificate to obtain the assurance from the CA. 
- Could you elaborate on where you see the major benefits of having a CA
assurance?
- Is the benefit greater for ECC?


On Proof-of-possession:
Section 5.6.3. of SP 800-56 states:

"For example, this Recommendation requires that parties obtain assurance
that they actually possess their own static private keys, and a binding
authority is required to obtain assurance of an owner's possession of
the appropriate static private key before binding an identifier to the
owner's static public key."

So since POP always MUST be performed by the CA there seems not to be
the need for diverse policies (POP and non POP).

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