Subject: Re: Certificate Policy Standardization

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 Nov 2003 04:13:30 +1300

"Anders Rundgren" <[email-masked]> writes:

>1. Why does practically no shrink-wrap PKI-enabled software package support
>any kind of certificate policy settings?

Zero demand.  Heck, it wasn't too long ago that MS PKI software hardcoded the
Verisign policy into CryptoAPI, so that no matter what the actual policy was
in the cert, what was displayed was the Verisign policy.  That shows how much
attention people are paying to the policy stuff.

That doesn't mean that RPs don't use a policy-equivalent: The software is
configured - via trusted roots - to only accept certs from a given set of CAs
(Anders, that's the policy-configurability you asked for, it's just not called
that).  So the trusted-roots mechanism does what the policy extension is
supposed to do, and the policy extension becomes a legal self-defence
mechanism for the benefit of the CA.  This is an almost complete inversion of
what RFC 3280 thinks that the policy extension is meant for:

  Applications with specific policy requirements are expected to have a list
  of those policies which they will accept and to compare the policy OIDs in
  the certificate to that list.

Peter.

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)

In message <[email-masked]> on Thu, 27 Nov 2003 04:13:30 +1300, [email-masked] (Peter Gutmann) said:

pgut001> "Anders Rundgren" <[email-masked]> writes:
pgut001> 
pgut001> >1. Why does practically no shrink-wrap PKI-enabled software package support
pgut001> >any kind of certificate policy settings?
pgut001> 
pgut001> Zero demand.  Heck, it wasn't too long ago that MS PKI
pgut001> software hardcoded the Verisign policy into CryptoAPI, so
pgut001> that no matter what the actual policy was in the cert, what
pgut001> was displayed was the Verisign policy.  That shows how much
pgut001> attention people are paying to the policy stuff.

Let's take note of what Peter says here.  First, M$ did some
hardcoding, which they have subsequently changed (I got that right, I
hope).  That means M$ is capable of change, and does listen to some
concerns.  Sure, that's pretty slow development, but development
still.  A bunch more times with a LART, and even M$ might do policy
checks :-).

pgut001> ...  So the trusted-roots mechanism does what the policy
pgut001> extension is supposed to do,

Which only works as long as the formula CA<=>Policy is true...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
You don't have to be rich, a $10 donation is appreciated!

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 26 Nov 2003 17:33:49 +0100

<snip>

>that). 

Peter, this is basically what I call de-facto standard.  I.e.

                     CA <==> Policy

>So the trusted-roots mechanism does what the policy extension is
>supposed to do,

Here we approach the core issue.

The problem is that it is fully RCFxxxx-complient to issue
any number of technically- or legally-wise different certificates
(with or without embedded policy OIDs) under a given CA root.

That means, that using [most] existing RP software, you may end-up
"trusting" or processing things that you maybe _did_not_intend_to.
I.e. here we have a standards-sanctioned SECURITY HOLE and a
blatant INTEROPERABILITY DEFICIENCY of great magnitude.

How come this has never been addressed?
Because most PKIs are local and then it is an in-house issue.

The (non in-house) commercial CA sector have since years back
opted not to exploit a feature (multiple issuances/root) that:
- Is legally dangerous (much higher risk)
- Is technically not supported by applications
- Is hard to understand
- Does not solves a single _important_ problem
(that multiple CA keys would be a "problem" is simply ridiculous,
for whom would it be a problem?  Is policy OID config (if there
really was one....) "easier" than installing a root-key?

<snip>

>This is an almost complete inversion of

>  the certificate to that list.

Yes, and I believe all this should be reflected in a MAJOR update of RFC3280.
Not that I expect this to happen.  We'd better cling to the time-proven de-facto
methods, and continue to ignore standards that are not updated in spite of
having huge problems and close to zero acceptance in some very vital areas.

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)

-----

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)

-----

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Wed, 26 Nov 2003 17:44:58 +0100 (CET)

-----