Subject: Re: NR Signing-Entity vs Certificate-Subject

From: Ed Gerck <[email-masked]>
Date: Tue, 23 Nov 1999 11:07:58 -0800

Irene Gassko wrote:

> >So, retaining "signing entity" is to retain a dangling reference.  To use
> >"keyholder" only makes sense in X.509 if it means the "certificate subject".
> >So, why not call the thing by its name?  "Certificate subject" is all we can
> >point our finger at -- and, if the certificate subject is NOT the only
> >keyholder then it is up to the certificate subject himself to deal with it,
> >certainly not the CA and certainly not X.509.
> >
>
> Here is the problem with this as I see it. Suppose that an enterprise generates
> (private,public) key pairs for its employees and distributes certificates
> to them.
> As a result of a software bug the same key was put into certs of two different
> persons. One of them signed a document and now claims that the other one
> is the real signer. Unless we have a provision that NR==1 requires saving
> a hash of a certificate used for authentication, how do we know who it was?

Irene:

This example is outside the scope of X.509 because the second person would not
have the corresponding private-key (which is kept private to the certificate
subject and is unknown to the CA, in X.509).  Thus, the second person could not
have signed though she could have received a certificate with an exact copy
of the first public-key, by a software bug.

But, what could happen in X.509 is the reverse of what you say -- the second person
could claim that she is the real signer, providing a certificate with her DN
and the first person's key in order to prove it. This would be an impersonation,
a crime in may jurisdcitions.  It is a good example when the CA has to deal with
it because the fault lies at the CA (in other words, we can't point our finger only
at a certificate's subject).

And, some moons ago I also suggested using the certificate hash as an
"intrinsic DN" for the certificate subject in this very discussion, as well as
two years ago.  However, there are other solutions with varying degrees of
effectiveness, such as saving the DN of the signer (which does not, however,
have to be unique even in the same CA), the certificate serialNumber (which
also does not work well and may be repeated by a software bug), etc.

The solution to this "impersonation-bug" scenario (in either case -- when the
CA generates private-keys and when it does not) is thus first to recognize
that the liability falls squarely on the CA's shoulders, which can be somewhat
reduced if the CA cooperates and goes out in an effort to prove that the second
person did not sign -- which may be impossible if the second person also
obtained the corresponding private-key by directly attacking the first person's
machine (a known target, by querying the CA for the owners of the public-key).
Note that the CA may not suspect the glitch, since different subjects may
have the same key (for example, your own different email names in different
ISPs).

Now, of course, the CA can use available NR services that the first subject
*himself* might have decided to use. Which NR services may or may not
depend on that CA and may or may not provide the level of detail
*and* the level of verifiable assurance that could indicate the actual signer
in a balance of probabilities .  So, "you get what you pay for" is also valid here
and the CA might wish the first keyholder had used a more comprehensive
NR service, but this call is not for the CA to make.

Regarding the use of the name keyholder, yes it is ambiguous and that
is why Section 3.3.3 of X.509v3 defines a certificate as: "The public keys of a
user, *together  with some other information* [MY EMPHASIS], rendered
unforgeable by encipherment with the private key of the certification authority
which issued it.".  In other words, the certificate is not only the signed key. That
"some other information" is provided in order to enable a relying-party to
verify the certificate *and* the certificate subject before accepting it -- whereby
ambiguity can be removed as much or as little as allowed for by the CA's CPS.
And, we need also to keep in mind that a CA's assurances in verifying any
data in a certificate may not be the assurances you need for your purposes.

Cheers,

Ed Gerck

---

From: "Aram Perez" <[email-masked]>
Date: Tue, 23 Nov 1999 11:40:14 -0800

Irene Gassko wrote:

> Will renaming NR bit into "archival" or "persistent" signature bit (as
> opposed to "ephemeral")
> make everybody happy? If yes, then we need to state what additional steps
> are to be
> associated with it.

First define "archival" or "persistent" with respect to keyUsage.

Regards,
Aram Perez