[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Multiple certificates for same key?
- To: IETF-PKIX@xxxxxxxxxxxxxxxx
- Subject: Re: [IETF-PKIX] Multiple certificates for same key?
- From: Tony Bartoletti <azb@xxxxxxxx>
- Date: Tue, 3 Mar 1998 19:10:49 -0800
- Approved-by: Tony Bartoletti <azb@LLNL.GOV>
- In-reply-to: <34FBD0CD.BC22A228@darmstadt.gmd.de>
- References: <>
- Reply-to: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@xxxxxxxxxxxxxxxx>
- Sender: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@xxxxxxxxxxxxxxxx>
I am not a lawyer, and I don't claim to appreciate fully the legal issues
surrounding a CA and their obligations, in either general or specific cases.
The arguments put forth in deprecating multiple (independent) certification
of a single keypair are reasonable, but I point out that they belie the
purported nature of X.509 certificates as "identity certificates" (that is,
to bind the key simply to a warm body able to appear court.) Rather, they
become attribute certificates, attesting to (say) primary residence, not so
much for distinguishing among similarly named individuals but now assuming
a free standing legal significance. The certificate no longer attests only
that a given document was signed by me, it can now be used as evidence that
I reside at location X, *independent* of my use of the key at all. While I
can appreciate the utility of such usage, I question where the boundaries lie.
Allowing independent certifications on a single key can be compared to the
use of both a "Diner's Club" card, and an "Auto Club" card. If stranded
in a broken car, the tow truck operator will be uninterested in my Diner's
Club card, whether valid or not. They want my Auto Club card, and want to
be assured that it is considered to be in effect at the time of transaction.
True, a key compromise on one should affect all certificates over that key.
If one certificate is not revoked, but should have been, it could just as
easily be the certificate appropriate to the transaction as the one not.
I wonder if the central issue is primarily one of protocol. The RP must
(somehow) obtain not just *any* certificate validating my ownership of the
key in question, but the certificate indicating I satisfy the role that the
relying party expects for a signatory to the given transaction. (In pure
"Identity Cert" principle, any such cert should just identify "me" to a
given degree of assurance, and then the relying party should use that fact
to determine if, within their own domain, this "me" has the required role.)
Again, I am not really advocating such usage, but I wonder if the restriction
is simply one of cert retrieval complexity, or if such usage would really
"break X.509". Has the structure so embedded these legal implications?
___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