Re: [IETF-PKIX] Multiple certificates for same key?

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Paul, although I generally hate to respond point by point, I both
agree and disagree with you, so I guess I have to:>
>
>>>> Paul Koning <pkoning@xedia.com> 03/04 2:33 PM >>>
>I'll skip quoting previous messages because it's hard to tell anymore
>who said what....
>
>One analogy presented was that several certificates for the same key
>is similar to having several credit cards in your wallet.
>
>It occurs to me that some of what's going on in this discussion is the
>age-old problem of mixing up authentication with authorization.  As in
>"am I dealing with G. Paul Koning, that guy with the bushy beard,
>passport number foo...?" vs. "given that I believe I'm dealing with
>G. Paul Koning, is he entitled to charge $N to account number bar?"
>
>It seems pretty clear that a pile of certificates all attesting to the
>same key are certifying the same identity, i.e., authenticate the same
>entity.  But because they have different attributes, they may be
>driving different authorization decisions.

Quite correct.  If the identity is "you", you signed it, and "you" are liable.
But there is quite a difference between signing something in your
personal capacity vs. singing something as an authorized agent for
someone else, even though it is "you" who signed it in both cases.

Ask your corporate attorney what it means for your CEO to order
car and sign it "Bill Smith" vs. William A. Smith, President, XYZ Corp.
In the second case it is XYZ who is liable, not Bill personally.

>
>In other words, it looks like the question is: are certificates
>supposed to be authentication tools, or also authorization tools?

My point is that whether explicitly or implicitly, attributes other than the user's
common name imply, or at least tend to imply, some degree of authorization,
willy nilly.

>
>If only authentication tools, then that seems to leave only the case
>of recertifying an existing key as a meaningful scenario for multiple
>certificates.

And even that raises potential issues about CRLs.
>
>If also authentication tools, then clearly there can be many
>certificates since any individual is allowed to do many things, and
>those permissions are granted by many independent organizations.
>
>In the latter case, while it may be possible to have many different
>key pairs for those many authorizing certificates, I agree with Bill
>Burr that this is a bad idea.  The more bits of secret I have, the
>harder it is to protect those bits.

This is where I would take exactly the opposite view. if you cannot
tell which certificate is supposed to be used for what purpose, then
you don't know whether a particular authorization was valid or not.

(BTW, from an information theory standpoint, and particularly
from a covert channel analysis, the more bits of a secret
you have, the EASIER it is to protect it.  If you wrap up all of
your secretsin one short crypto key, it becomes extrarodinarily
difficult to protect it from a covert channel attack. but that's a
different issue. Of course covert channels, like Tempest attacks,
are not considered feasible, said the ostrich with his
head firmly in the sand.)

>
>Another point: if certificates are authorizing tools, you aren't
>actually going through the two step process of first authenticating
>then authorizing.  So it isn't functionally necessary to be able to
>prove that each of my authorizing certificates "belongs to" the same
>identity.  On the other hand, it seems to be very useful to be able to
>do this -- which is what you get by having them all tied to the same
>key.
>
>Finally, a thought that may not work... if there are many certificates
>sharing a key, it would make sense for revocation to revoke the key,
>not each certificate one by one.

Well, of course Carl Ellison and the SPKI crowd would agree with such
a key-centric view, but that would tend to further compound the problem of
blurring attributes associated with a particular key.
>
>        paul

Bob