Subject: Public key validation and Proof of possession

From: Russ Housley <[email-masked]>
Date: Tue, 25 Oct 2005 17:03:55 -0400

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

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Wed, 26 Oct 2005 11:01:29 -0400

Hi Russ,

I have no problem with defining extensions for this, but I think it would
need to be made very clear somewhere what checks must be performed if the
public key validation extension is asserted.

For DH for example, does it imply that subgroup membership ((g^x)^q=1 mod
p) has been checked? Not all protocols use subgroups for DH, do they?

Other algorithms are harder. What exactly does public key validation for
RSA or NTRU or XYZ mean?

I think the key here is that in some cases checking 0<g^x<p may be enough.
In others subgroup membership may also be needed. As a relying party I
need to know.

I guess the checks that are performed could be specified in the CPS, but I
think it would be better put in the RFC itself.

Best regards. Simon

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Tuesday, October 25, 2005 5:04 PM
> To: [email-masked]
> Subject: Public key validation and Proof of possession
>
>
>
> Dear PKIX WG:
>
>        2. TTP Full Validation - The recipient receives
> assurance that a trusted
>        3. TTP Generation - The recipient receives assurance that a
> trusted third

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Oct 2005 12:45:24 -0400

Russ,

I think this is a good suggestion, and the extension should be a 
simple as you suggest.  Relying on this being in a CP is asking a lot 
in management terms, as you noted.

However, one might also address this by defining an IETF-standard CP 
that addresses just these issues, and allowing CAs to add that CP to 
whatever other CP that assert in an cert.  How do you feel about that 
alternative?

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Oct 2005 12:11:20 -0400

Simon:

I agree that the check need to be specified.  And, we would require 
that successor documents to RFC 3279 would need to specify the 
criteria for setting the bit for that algorithm.

In the development of ANSI X9.44, there was an informative annex on 
RSA Public-Key Validation and Plausibility Tests.  I have not looked 
to see if it is in the most current version, but this is the checking 
that would be performed by the CA to set the bit.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Oct 2005 15:18:09 -0400

Steve:

If I understand your proposal, you are suggesting a certificate 
policy OID that would be included in the certificate (in addition to 
any other certificate policy OID that is appropriate).  This would be 
acceptable to me if it was only used in end-entity certificates.  I 
think it could add complication to certificate policy mapping, which 
is already too messy.

I note that the certificate policy OID does not offer the same 
granularity.  The OID would only be included if the public key 
validation is performed and proof of possession is performed.

Russ

At 12:45 PM 10/26/2005, Stephen Kent wrote:
>simple as you suggest.  Relying on this being in a CP is asking a 
>lot in management terms, as you noted.
>
>whatever other CP that assert in an cert.  How do you feel about 
>that alternative?
>
>Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Oct 2005 20:17:33 -0400

At 3:18 PM -0400 10/26/05, Russ Housley wrote:
>any other certificate policy OID that is appropriate).  This would 
>be acceptable to me if it was only used in end-entity certificates. 
>I think it could add complication to certificate policy mapping, 
>which is already too messy.
>

I envisioned two policies, one for each of PoP and PKV.

However, If Stefan's observation about policies is correct (I admit 
to having not checked first), then this is not a viable alternative 
to your proposal, even independent of the policy mapping complexity 
concerns your cited.

Steve