RE: Public key validation and Proof of possession

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Russ,

Yes, there may definitely be new low-end devices.

But how many low-end devices do validate a large number of certificates
from other entities on its own?

Have you considered using the qcStatement extension in RFC 3739, it's
actually designed to deal with things like this.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
> Sent: den 27 oktober 2005 15:37
> To: Stefan Santesson; ietf-pkix@xxxxxxx
> Subject: RE: Public key validation and Proof of possession
> 
> Stefan:
> 
> I think that there will always be low end devices.  Consider the
history.
> 
> - Personal computers used to be very simple systems, especially
> before the IBM PC.  Remember the Intel 8080?  A very large machine
> had 32 Kbytes of RAM, and non-volatile storage was 8-inch floppy disk.
> 
> - Hand-held computers were originally very low-end computers.  They
> have come a long way, and the power management has significantly
> helped with battery life.
> 
> - Mobile phones did not really include Internet capabilities at
> first, but when they were added, WAP was used to accommodate the
> low-end processing environment.  When 32-bit processors appeared in
> mobile phones, mainstream Internet protocols were used in favor of
WAP.
> 
> - Smartcards are still low-end processors.  As you point out, they
> are getting more powerful all the time.
> 
> - RFID are very low-power devices.  I'm sure that more capabilities
> will be added over time.  But right now, certificate parsing and
> validation is probably beyond their capabilities.  As they become
> more capable, I think that certificate-based protocols are
> appropriate in this environment.
> 
> In summary, I do not think it is unreasonable to consider features
> for low-end devices.  I believe that there will always be new low-end
> devices appearing, and at some point they may need to handle
certificates.
> 
> Russ
> 
> At 05:37 PM 10/26/2005, Stefan Santesson wrote:
> >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