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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Tony,

As you can imagine, I have had difficulty reading and responding to all
of the hornets at once, as well, so some of our mail has crossed.
I too hope the bandwidth expended has been worth it.

I think the point that I have been trying to make is that although
hashing the public key and saying "yes, SOME certificate exists and is valid
that matches that key" would establish the fact that the possessor of the
private key signed a document, there are inevitably, I argue, various
roles or other kinds of at least implied attributes that may have to be taken into
consideration, especially by the relying party.

The root problem is that the specific certificate which is intended to be used
to validate a digital signature is not crypotographically bound to the digitally
signed text, making it cryptographically ambiguous which certificate cum attributes
was intended to be validated.  In a sense, that is a fundamental flaw in the ASN.1
definition of a digital signature. It could be fixed, of course, and probably much
more easily repairing all of the various protocols that will ever use the Signed
macro, but I suspect that even though we are still at the dawn of this new era
and could fix it rather easily, we won't do that. "You can pay me now, or you
can pay me later." Sigh.

Anyway, thanks (blame?) to Stephan Kelm for raising this thread.
Every so often, we need to revisit our original assumptions and make sure
they are still valid.

Bob

>>> Tony Bartoletti <azb@llnl.gov> 03/04 2:53 PM >>>
Bob,

Thanks for considering my comments.  I didn't see them until after sending
_yet_another_ diatribe on the issue.

While I am concerned about privacy issues, the real thrust of my exploration
was to ferret out, by way of implication, what cert-chain mechanisms folks
expect to exist.  The comments of some lead me to believe that an OSCP-type
responder could simply be submitted a public key (or its hash) and then it
would respond, boolean-wise, with "Yes, there IS a valid cert of some form for
that public key" or not.  That is, as if there would be no provision for the
(e.g., OCSP) user to specify a cert, or a set of attributes that must be
present to indicate the key is suitable for their purposes. Such a system
could only work if there were exactly one cert-per-key, so *the one* cert
(hence *the one* key) is either valid or not.

I hope all of this is of value to someone;)

___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