Subject: General purpose OId's for certificate policies?

From: [email-masked]
Date: Sun, 9 Mar 2003 14:37:34 +0100

Hi,

I've been trying to understand how the certificate policy extension of a 
certificate is used today and to which extend current and future 
PKI-dependent applications can make use of it. I tried to find examples of 
certificate policy OId's, but the few I found seemed to be limited to a 
particular CA, a particular organization, a particular application (like 
server authentication --- presumably TLS/SSL), etc.

My first question is therefore; is the current practice for each CA to define 
their own certificate policy OId and maybe even a new OId for each 
organization to which the CA has issued certificates to?

It seems reasonable to have such highly specialised/limited scope OId's in 
some PKI deployments. However, for large volume commercial products like 
PDA's and cell phones, it seems difficult to provide a general, managable, 
and userfriendly mechanism for updating the configuration of the terminals 
with knowledge of the correct policy OId's. During the production of such 
terminals, it is typically not known where the terminal will be deployed, so 
it seems that it is in general not possible to preconfigure the terminals 
with the correct OId's, either.

For the end-user, it would probably be easier if, for example, there were 
generally agreed upon policy OId's for web server authentication (class 
1/2/3, etc.), email signature validation, etc. I am thinking along the lines 
of the policy OId's defined for the extendedKeyUsage (althought the two 
extensions are used differently in the path validation algorithm) with the 
addition that some generally agreed upon graduation of what policy is implied 
(the class 1, class 2, class 3, etc.).

My second question is therefore; does anyone on this mail list know whether 
such general purpose policy OId's exist (for use with commercial/public 
internet services), or if initiatives to define such Oid's are ongoing? (If 
yes, I would be very interested in some links to the relevant sources.)

Or, is it so that when it comes to, e.g., typical deployments of TLS/SSL over 
the public internet, the certificate policies extension is not seen useful at 
all? What is the general opinion on this from todays CA's?

What I have in mind is that there can be many different applications running 
on top of, say, TLS. If a key usage extension is present in a TLS server 
certificate, then RFC 2246 states what this extension must contain for the 
client to accept the servers certificate. But how can one tell (based on the 
server certificate) whether the server is allowed to use TLS for WEB content, 
only, or for both SMTP and WEB content (thought-up examples)? I was thinking 
that exactly the certificate policies extension could help the client to 
differentiate between these situations. How do todays CA's see this? Is this 
kind of differentiation irrelevant for their trust models?

/bv

---

From: Roger Younglove <[email-masked]>
Date: Mon, 10 Mar 2003 08:31:17 -0500

Comments interspersed

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [email-masked]
www.networksgroup.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, March 09, 2003 8:38 AM
To: [email-masked]
Subject: General purpose OId's for certificate policies?

Hi,

My first question is therefore; is the current practice for each CA to
define 
their own certificate policy OId and maybe even a new OId for each 
organization to which the CA has issued certificates to?
**ry, Yes each CA registers an OID to identify its self and uses an
extension of that OID to identify the CP that the cert is issued under. If
there are more than one type of cert issued by that CA the OID identifies
each CP used. This allows a RP to identify the issuing CA and CP and make a
decision at if the cert is acceptable for the particular use to which it has
been applied.

of the policy OId's defined for the extendedKeyUsage (althought the two 
extensions are used differently in the path validation algorithm) with the 
addition that some generally agreed upon graduation of what policy is
implied 
(the class 1, class 2, class 3, etc.).

**ry, Not to my knowledge. 

Or, is it so that when it comes to, e.g., typical deployments of TLS/SSL
over 
the public internet, the certificate policies extension is not seen useful
at 
all? What is the general opinion on this from todays CA's?

server certificate) whether the server is allowed to use TLS for WEB
content, 
only, or for both SMTP and WEB content (thought-up examples)? I was thinking

/bv