RE: Public key validation and Proof of possession

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Russ,

I'm concerned that we are about to enter a dangerous path if we start
defining extensions for policy aspects. If we open this can, there are
many other potential candidates for policy expression extensions and I'm
not sure we will help the deployment community by going down that path.

I think this needs careful consideration and I'm not sure the benefit of
this extension is worth the cost.

My thought is that arithmetic property validation seems feasible even in
a smart card today and even more, this test can easily be done in the
system in which the smart card is used. Computation power is
exponentially increasing and before this extension is generally adopted,
this might very well be a completely redundant issue.

POP of encryption keys seems to be such a generic requirement for CAs
that even policy enforcement through trust anchor chaining might be
sufficient in most cases.

I think it would be good to have some discussions in Vancouver if this
can be fitted into the pkix agenda.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
> Sent: den 26 oktober 2005 15:39
> To: Stefan Santesson; ietf-pkix@xxxxxxx
> Subject: RE: Public key validation and Proof of possession
> 
> Stefan:
> 
> >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.
> 
> In low power devices (such as smartcards), avoiding the y^q
> exponentiation because the relying party is sure that the CA has
> already performed this check seems useful.
> 
> >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?
> 
> If the first idea is accepted, the proposed extension is no larger by
> adding the additional bit to indicate that the CA performed POP.  The
> positive statement could be useful.
> 
> Russ