Subject: RE: Public key validation and Proof of possession

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 26 Oct 2005 22:37:22 +0100

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:[email-masked]]
> Sent: den 26 oktober 2005 15:39
> To: Stefan Santesson; [email-masked]
> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Oct 2005 09:37:03 -0400

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

---

From: Michael Ströder <[email-masked]>
Date: Fri, 28 Oct 2005 08:38:02 +0200

Stefan Santesson wrote:
> defining extensions for policy aspects.

A very valid concern.

> If we open this can, there are

I couldn't agree more.

How about candidates like "Power and air conditioning", "Water
exposures" and "Fire prevention and protection". I'm pretty sure a
relying participant should be able to check these aspects automagically. ;-)

> this extension is worth the cost.

It's my impression that X.509v3 extensions are not fully supported in
today's implementations anyway. Therefore each new extension will likely
not be adopted by implementors but will complicate the standards.

> this might very well be a completely redundant issue.

+1

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 28 Oct 2005 08:44:44 +0200

Russ Housley wrote:
> 
> - Smartcards are still low-end processors.  As you point out, they are
> getting more powerful all the time.

In a real-world project I'd prefer to spend more money for a more
powerful smartcard over messing around with applications which are badly
implemented because the standards are getting too complicated.

> - 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

But extending high-end certificate-based protocols to cover low-end
devices likely will make the protocols too complex to be ever securely
implemented.
=> PKIX should be limited to where it's applicable in the real world.

Ciao, Michael.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Oct 2005 14:44:19 -0400

>implemented because the standards are getting too complicated.

a fair choice, IF you get to make it. But in many 
contexts organizations will issue smart cards and 
users will have no option to spend more for a 
more powerful model. the decision on how much to 
spend will be made by the organization, with 
little of no input from users.

>=> PKIX should be limited to where it's applicable in the real world.

I suspect that many of us agree that making a 
standard too complex does have the potential to 
reduce security. the problem is always deciding 
where to draw the line.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 Oct 2005 14:44:19 -0400

Steve