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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Tony, I didn't go back to check, but I may have been guilty of the less
than precise usage implied by "which certificate was used to sign".
Obviously you are correct -- private keys sign documents, not certificates,
so the more correct usage would be "which certificate should be used to
validate a document that was signed by a private key which is mathematically
bound to a public key, which is in turn bound to some collection of attributes
and/or names in the certificate by the Certification Authority, based on
representations made by the subscriber and verified (more or less, as
spelled out in the CPS) by the CA." Sorry if I skipped a few steps in the terminology.

(What is the ASN.1 for "do what I mean, not what I say"?)

The problem, to the extent that there is one, is that the X.509 definition of the
"sign" macro does not provide any means of defining precisely which
certificate in particular should be used to validate a particular signature,
and thereby associate a particular set of name/rights attributes with that
signature.

(That's what often happens when a standard that was intended for one purpose
is appropriated for another, entirely different purpose. We, the digital signature
community, probably should have rethought that particular issue before adopting
the X.509 definition of signature. Some other information, such as the date/time and
signing and the identity of the platform ("location") on which the signature took
place would have been handy, also.)

But that's water over the dam by now, and so all of the various applications
which might ever want to use a digital signature have to solve the problem themselves.

Unfortunately, several of those applications further compounded the
original error by not incorporating an unambiguous reference to the certificate which
is to be used to validate the signature within the signed document itself, but rather
appended the reference to the certificate, or the certificate itself, to the document
in an insecure manner. One way around that problem would be to recite the
contents of the certificate itself, but that is both awkward, and not likely to be easily
machine processable, since no particular convention has been established for such a
process.

Since the certificate reference is not securely bound to the document in question,
another certificate could easily be substituted. If it were not for the private key
proof-of-possession requirement, this would even allow some other person to
claim authorship of the document, which might be quite useful in some circumstances.
And it certainly allows an individual who possesses the key but is wearing different
hats (roles) to play some games if it would be to his advantage.

To address your concerns, therefore, I submit that it matters a great deal to the
relying party whether the certificate that is used to validate a digitally signed document is
the Classy Certificate which identifies you as the purchasing agent for your company,
vs. the one which identifies you as the secretary of your bowling team, vs. the one for
you in your private citizen capacity, all of which had a common public key.

Although from a legal standpoint, it is "you" that signed the document in each case,
and hence "you" may be personally liable if your signature was not duly authorized
for that type of transaction, from the standpoint of the relying party "you" in your
private capacity may not have sufficient funds to pay for the nuclear reactor that
you just ordered in your capacity as an agent of Lawrence Livermore.

To put a different spin on it, suppose that you work for Unscrupulous Employer, Inc.
as an officer, director, or agent. You order 1 million blue widgets in the name of
your company in good faith. Unfortunately, by the time they arrive, the bottom
has dropped out of the blue widget market, and now everyone wants red ones.
Your employer is facing bankruptcy if they have to pay for the blue widgets, so some
way or another they manage to remove the company certificate from the signed
document and substitute your own personal certificate which contains the same key,
leaving you twisting slowly in the wind. Since widgets cost $10 apiece, the widget
manufacturer sues you for $10 million. He won't collect more than a few hundred
thousand after he sells your house, so both of you will be pretty upset.

You will both argue that it wasn't your private capacity certificate that was intended to
be referenced, but rather the company's Classy Certificate, and offer "proof" in the form of
the original document as received, but the Unscrupulous Employer can argue that you
change the document after it arrived, and that his copy was the correct one. At least
from a cryptographic standpoint it is indeterminate whose certificate was supposed
to have been used to validate the signature.

I suppose that once this problem is adequately recognized attorneys will advise the
clients not to rely solely on the certificate to establish authorship, but to include
a claim of authorship in the document itself, and to insist on such a reference
being in any signed transaction that is to be accepted, but as a technologist
I would prefer a technical solution.

Bob
>
>
>
>>>> Tony Bartoletti <azb@llnl.gov> 03/04 1:18 PM >>>
>Pardon, please, my pedantic revisitation of this topic, but some of the
>comments that have been made imply (to me) a peculiar stance on the
>relationship between keys, certificates, end-entities (EE) and relying
>parties (RP).
>
>More than once, I have seen expressed "which certificate was used to sign"
>a document or transaction.  I thought that a "private key" was used, and is
>not a component of any certificate directly.  I think of a private key as
>having (potentially) a life of its own, possibly independent of any
>certificate (albeit not of great use where not certified in some capacity.)
>
>Where does the following example "fall down"? :
>
>In my hypothetical role as Purchase Officer for BigCorp, I obtain a classy,
>expensive certificate for a key, attesting to my identity and role, and
>obligating me to protect such key to the level of assurance indicated by
>the certificate.  I also have this key certified by Certs-R-Us as belonging
>to me in the capacity "member of chess club in good standing" (with a very
>low degree of assurance provided, and so a low cost.)
>
>I sign a purchase order on behalf of BigCorp.  The relying party must verify
>this signature, and so must obtain a some certificate by some means.  Simply
>verifying that some arbitrary public key verifies the signature is not
>enough.  It must be a *suitably certified* key.  If I point the RP to my
>"chess club" cert, the signature may verify, but the transaction should not
>proceed.  How could it?
>
>Also, how could my act of obtaining a "cheap cert" on the same key weaken
>in any way the relationship this key has to me in my BigCorp role, or my
>obligations to protect said key in accord with the provisions indicated in
>the classy, expensive certificate?
>
>Finally, I say all of this, not to advocate multiple certification of a key,
>(keys will NOT be a scarce commodity) but to understand the "liability issues"
>alluded to by some in this discussion.  I even wonder if there is a fear that
>"cheap CAs" might leverage the strong (pre-existing) certification on a key
>to issue additional certifications, attesting to whatever the owner-in-common
>would like, in essense conditioning the validity of their new binding on the
>continued validity of the "classy certificate."
>
>___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