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

From: Roger Younglove <[email-masked]>
Date: Tue, 11 Mar 2003 08:24:44 -0500

Steve
I respectfully disagree on one of your points. See comment 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: Steve Hanna [mailto:[email-masked]] 
Sent: Monday, March 10, 2003 5:02 PM
To: Anders Rundgren
Cc: [email-masked]; [email-masked]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)

>I've been meaning to correct a comment you made in an
>earlier message:

>Chris Gilbert wrote:
> > The two are likely to contain different certificatePolicies.

>You responded:

>> <CertificatePolicyRant>
>> It is interesting to note that CPSs are frequently mentioned in this
>>context
>> in spite of the fact that none of the major crypto-packages (Windows
>> and Java) offers any way to specify CPSs as a part of a CA trust
>>acceptance
>> process.  The reason for this is simple: Computers don't understand
>> legal matters and CPSs are deployment-wise anything but standardized.
>> Peter Gutman's term "Kitchen sink extensions" is a fair description of
>> the value of CPSs for practical purposes.  Do "SysAdmins" ever
>> bother about the CPS of their VeriSign web-server certificates?
>> My Thawt web-server cert does not even have a CPS extension and
>> I haven't missed it that much.  CPSs were designed by lawyers for
>> lawyers.  But lawyers do not run e-business systems, write application
>> software packages, or know how to handle a Java keystore.
>> </CertificatePolicyRant>

>You're confusing a Certification Practice Statement (CPS)
>with a Certificate Policy. A CPS is typically written by
>lawyers for lawyers and can't be evaluated by a machine.
That is not true a CPS is the technical "how it is done" to the CP.
The CP places requirements on the operation of the CA and RA, the CPS states
how those requirements are met. Written by technicians for technicians to
evaluate. 
>But that doesn't mean that the Certificate Policies
>extension isn't useful or supported. It's a completely
>different beast.
<snip>
Thanks,

Steve

---

From: Tim Moses <[email-masked]>
Date: Wed, 12 Mar 2003 13:51:06 -0500

Colleagues - Another unfortunate side-effect of implementing a distinct
hierarchy for each policy is that, in order to sign a transaction, the
signer has to choose the key/certificate/hierarchy/policy that will be
accepted by the relying party for the particular transaction.  If he/she
chooses wrongly, then the transaction will be rejected.

On the other hand, if the signer only has one key/certificate, then the
signer has no choice to make.  He/she signs the transaction with his/her
only key and (if a suitable certification path exists) the relying party
discovers and validates it in accordance with its policy requirements.

Of course, solutions could be developed to solve this problem for the case
of distinct hierarchies, but the solution already exists and is thoroughly
tested for the "multiple-policies per certificate" case.

All the best.  Tim.

-----Original Message-----
From: Steve Hanna [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 10:39 AM
To: Anders Rundgren
Cc: Santosh Chokhani; [email-masked]; [email-masked]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)

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

---

From: [email-masked]
Date: Thu, 13 Mar 2003 10:30:48 -0700

a similar argument was used with regard to plastics cards turned smartcards
.... however the most common failure was lost/stolen wallet containing all
such cards. there was absolutely no difference with management issues
whether there was a signle card or multiple cards .... for the most common
failure/exploit.

postulated was that the next most common failure (fraud, exploit,
availability, etc) might be hardware failure. however, the hardware failure
scenarios statistics didn't mandate a one-for-one mapping between token &
function .... it would just indicate that some might want
no-single-point-of-failure (two tokens, or at most three).

I would assert that if you need/require multiple certificates .... that
there is effectively nearly the same management process ... regardless of
whether a single key or multiple keys are involved.  You have to a mapping
between key to which certificate .... whether it is one-to-one or
one-to-many .... and you have to have a notification process for each
certificate. The issue then isn't the management of the information .... it
is just how many that might have to be notified for each key compromise ...
not the management problem of keeping track of all that might have to be
notified. It is slightly different if the information hasn't been managed
and it is necessary to reconstruct it after a compromise ... then if there
is only a one-to-one mapping .... then the scope of reconstruction may not
be as bad ... since the search for key-to-certificate mapping stops after
the correct certificate has been identified ... and the search for
notification process stops ... after the process for the specific
certificate is found.

issue with regard multiple or single key compromise .... would be if the
compromise modes have common components. For instance are all private keys
carried in the same hardware token or same encrypted file. If the most
common compromise/failure mode for keys .... are common multiple key
failure ... aka attack on encrypted file containing all private keys ....
then all certificates have to be revoked .... regardless of whether there
is a one-to-one policy or a one-to-many policy is allowed (aka similar to
the most common failure mode for cards .... the lost/stolen of wallet/purse
... where all cards are taken .... and there is no differentiation in this
failure mode whether there were single card or multiple cards .... all
cards fail). semantic note: "common" is used in the sense of "most
frequent" ... as well as the sense of "affectiing all keys".

I would also strongly assert that many policies are left over from
shared-secret key policies .... each infrastructure requiring a unique key
because of vulnerabilities specifically associated with shared-secret key.

I would contend that many of the vulnerabilities significantly changed
transitioning from shared-secret key infrastructure to public key
infrastructure .... and the vulnerability thresholds needed for various
organizations would still be met if the same public key were used in
different infrastructures ... aka many infrastructures never bothered
really redoing failure/vulnerability analysis. Possibly in the transition
from shared-secret to public; some bureaucrat just says that there is a
policy regarding keys .... and of course all keys are the same.
Bureaucratic policies have a life of their own.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Al Arsenault <[email-masked]> on 3/13/2003 7:40 am wrote:

><snip>
> * When using multiple CA-s, what prevents you from issuing multiple
> certificates to the same key?
>

From a technical standpoint, typically nothing prevents this.  It's not
commonly done because:

    a.  There's more of a management problem; e.g., if the key is ever
compromised for whatever reason, you have to track down ALL of the
certificates it was bound to and revoke them;  and

    b.  Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.