Re: Certificate Policies (was Re: Trivial PKI Question)

[Steve Hanna <steve.hanna@xxxxxxx>]

Anders Rundgren wrote:
> there is no reason to get excited :-)

I'm not excited, just trying to redirect the conversation
away from unsubstantiated attacks and toward solid technical
analysis.

> >The method you described (having a separate CA network
> >for each policy) is cumbersome. So, yes, I do think we
> >should work on getting support for certificate policies
> >into relying party software.
> 
> I know little about the systems that you indirectly refer to, but
> may I put some questions here?

Yes, this is good. We're having a real dialog, exchanging
information! As I said before, I'm not an expert on
certificate policies. However, I'll try to answer your
questions. Anyone who knows more about certificate policies
should feel free to jump in at any time. I also suggest
that you (Anders) might want to read RFC 2527 or the
Internet Draft that is being prepared to succeed it:
draft-ietf-pkix-ipki-new-rfc2527-01.txt. This describes
certificate policies in some detail.

> - What does separate CA networks mean more than multiple keys
>   (which should be piece of cake if you have proper CA SW)?

This is the system currently used by most commercial CAs.
They typically have a separate root CA for each class of
certificates (certificate policy). This root CA may certify
subordinate CAs, which are also typically separated by class
of certificate. Not only do you need a separate key pair
for each class of certificate, you typically use a different
CA name and have a separate set of CRLs. And, of course, the
number of trust anchors in relying party software increases
by a factor equal to the number of policies.

> - What do these policies imply (function: web-server/e-mail or
>   legal: hi-value/lo-value)? This is IMO a pretty broken part
>   of  policy extensions.  And very hard to "repair" as well

As RFC 2527 and X.509 say, a certificate policy typically
"indicates the applicability of a certificate to a particular
community and/or class of application with common security
requirements." Among other things, it might say what applications
the certificate can be used for or what warranties are provided.
So both "function" and "legal", in your terms.

Could you elaborate on why you think this is broken?

Personally, I'm concerned that the expense and inconvenience
of defining certificate policies and agreeing on them between
all the parties in a PKI is slowing down PKI deployment. I'm
interested in working on possible solutions to that problem:
standard CPs, minimal CPs, and other ideas. But this problem
arises regardless of whether you use the certificate policies
extension or establish a separate CA network for each policy.

Maybe your objection is to certificate policies in
general and not to the certificate policies extension
in particular. If so, how do you propose that CAs and
relying parties would agree on what the certificates
mean? And why should you object if some people want
to identify certificate policies in the certificate?
Nobody will force you to do so and it addresses their
requirements.

> - How does these guys plan to communicate outside of their
>   tightly matched (unique) system?

An application that requires one particular certificate
policy generally won't accept another policy unless policy
mapping has established that the other is acceptable.
For these applications, maintaining security is apparently
more important than being able to accept any certificate.
Other applications might not have such a requirement.

As for the merits of attribute certificates, directories,
the U.S. Government, etc., let's set that discussion aside
for now and focus on certificate policies. We can work on
those topics some other time.

Thanks,

Steve