Re: [IETF-PKIX] Multiple Certificates

[Paul Koning <pkoning@xxxxxxxxx>]

>>>>> "David" == David P Kemp <dpkemp@missi.ncsc.mil> writes:

 >> What is the foundation or context for this discussion: WHAT
 >> ATTACKS ARE WE CONCERNED ABOUT?

 David> Key compromise.

 David> If some other person gets a copy of my private key, that is a
 David> key compromise.  If I have a keypair certified for one
 David> purpose, and I take that private key and request that it be
 David> certified for a different purpose, that is a key compromise
 David> from one of my schizophrenic personalities to another :-).

I don't see the issue.

If your private key is compromised, your private key is compromised,
and the validity of all signatures made by that key is thrown in
doubt.  Whether the corresponding public key is attested by one or by
a million certificates makes no difference.

 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.

---
It seems to me that, given that many people view certificates as
things that describe authority (roles) and not identity, you're going
to have a pile of them.  And if you do, there are good reasons to want
to minimize the number of private keys.

To apply one of the standard analogies again: while I have one
identity, I have a lot of different authorizations (roles), and lots
of different pieces of plastic and paper attesting to these.  But my
signature on all of them is the same scribble.

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.

        paul