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

[Tony Bartoletti <azb@xxxxxxxx>]

At 10:16 AM 3/5/98 -0500, Charles W. Gardiner wrote:
>    Surely the document you signed as Purchasing Manager of BigCorp contained
>the name of BigCorp and your title.  The relying party should, therefore,
have
>looked up that certificate, not your chess club certificate.  You probably
>sent the classy cert. when you first placed a purchase order with XYX Corp.
>That's much the way the world works pre-digitally.  Digital signatures
will very
>likely follow in the same groove, well established by custom.
>
>Charlie Gardiner

I would hope so.  However, the comments in this thread imply otherwise.
You assume, I believe, that a human will be in the loop to read the purchase
order, and use this information to look up a certificate manually.  Perhaps
my purchase order example was not the best.  Please consider the comments of
Bob Jueneman, which I include (indented) below:

  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.

(Thanks again Bob, for the explanation.)  Although I read most of the postings
to the PKI mailing lists, I find there is rarely a presentation, high
level, of
what each automated protocol needs or expects in order to perform its
function.
Not long ago, there was debate about whether the relying party was responsible
for gathering the chain of certs to validate a transaction, ot whether it was
the duty of the supplicant (transaction submitter) to supply these, or at
least
their links, to the relying party.


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