Re: [IETF-PKIX] Multiple Certificates

[Tony Bartoletti <azb@xxxxxxxx>]

At 04:10 PM 3/6/98 -0500, responding to David Kemp, Paul Koning wrote, in
part:

> David> More realistically, if one CA's Certification Practices
> David> Statement says that subscribers will be required to keep their
> David> private keys in a FIPS-140 rated module, and another CA allows
> David> subscribers to keep them in unencrypted hard disk files, then
> David> if I happen to request certification of two keys which happen
> David> to have the same bit pattern from the two CAs, one of the CA's
> David> policies may have been violated.
>
>That doesn't follow at all.  You only get into trouble if the
>intersection of the requirements of the various CAs is null.
>
>In the example you quoted, all that's needed is that the private key
>has to be in a rated module, since one of the CAs requires that.  So
>long as the other CA doesn't have a policy *forbidding* the use of a
>rated module, you're all set.

I tend to agree.  More interesting, however, is the case given by David
that you did not explicitly address.  This is where the two certs demand
crypto-only and signature-only usage, respectively.  Granted, as such
the usage intersection should prove to be null, but this intersection
(as in the previous storage example) occurs in execution of policy, and
not in code.  Consider as well these two scenarios:

1.  Government usage for crypto will demand provision for key recovery.
Suppose they are silent on recovery of signature key usage.  In such case,
one would be conforming only if key recovery is available in both usages.
Not a great idea.  (Actually, a very bad idea.)

2.  Government usage for crypto demands provision for key recovery, but
also mandates strict guarantees against the possibility of key recovery
for signature keys (we should all demand this in my personal opinion.)
Such a demand precludes the use of a key for both purposes, and any
such dual-certification should produce the "empty intersection" that
you spoke of previously.  The question becomes one of enforcement.
Under such circumstances, it should be impossible to use the key, or
to have the second use certified.  At the very least, government should
demand that attempted dual use be detectable.

But how is software to know what other certifications a key may have?

>Using certificates to describe authorization means of course that I
>won't just check whether there exists a certificate that validates a
>signature -- I'd also check that the certificate is one that grants
>the kind of authorization I'm interested in.  For example, to
>validate, say, a dialup access attempt, I might look for a certificate
>issued by my company.

This principle I agree with as well.

>        paul
>

___TONY___


Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL