Comments interspersed
Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. ryounglove@xxxxxxxxxxxxxxxxx
www.networksgroup.com
-----Original Message-----
From: nojunkhere@xxxxxxxxxx [mailto:nojunkhere@xxxxxxxxxx]
Sent: Sunday, March 09, 2003 8:38 AM
To: IETF-PKIX@xxxxxxx
Subject: General purpose OId's for certificate policies?
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?
**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.
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.)
**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?
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