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: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Russ Housley
> Sent: Tuesday, October 25, 2005 5:04 PM
> 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
>
>