The problem with certificate serial numbers is that the same key is often
certified several times (by the same or different CAs) so it is sometimes
useful
to recognize keys by key identifiers rather than certificate serial numbers.
For this reason, we are currently introducing key identifiers into X.509
certificates. I see MIME/PEM key selectors as fulfilling basically the same
role.
I succeeded in convincing Bob if the following, so I'll try my luck on
you. :-)
Suppose you have one key certified by different issuers A and B (or
one key used for different roles, as in Bob's case). And suppose you
sign a message and use key identifier 1, meaning "key signed by
issuer A". If I modify the message in transit to have key identifier
2, how could the recipient possibly know? It's the same public key,
so the signature will verify just as well. If one key is certified by
different issuers, or linked to different names (like residential name
and business name), or used for different roles, then there is no
*cryptographic* significance to giving the distinction in the
Originator-ID, since any of the others could be indicated and the
message will still verify.
Jeff is right. But let's think about this for a second, as I remember having a
similar conversation with Steve Kent about a year and a half ago.
In the first place, I would say that CAs do NOT certify keys per se, but rather
they certify the binding betwseen a particular key and an identity/role that is
claimed by the applicant. As part of that function, they should require the
applicant to prove that he/she actually possesses the private key that
corresponds
to the public key included in the certificate.
Unfortunately, the CA cannot possibly verify that the user entity identified
within
the certificate has the EXCLUSIVE knowledge of the private key. In the case of a
user who choses to have multiple roles (e.g., as both an organizational and a
residential person) it is obviously possible for the same key to be used for
those
two potentially conflicting roles.
Similarly, given the possibility of collusion between two users, they could
share
knowledge of the same public/private key pair and create two certificates, even
under two different CAs, that would have a common key. I would have to think
for a
moment to see what sort of mischief could be created by such a scheme, but I
feel
distinctly uneasy -- enough so that I feel that this is NOT a good thing to even
tolerate, much less encourage.
I understand that it might appear to be a convenience to the user, and
especially
where the user might not want to carry multiple smart cards for every role. But
without this kind of logical separation, the very concept of having different
roles
becomes hopelessly blurred, and it becomes imposible to transfer a role to
another
person without generating a new certificate. It is for this reason that I would
greatly prefer to manage CERTIFICATEs, not keys, and I think that Peter Williams
has expressed somewhat similar thoughts.
In the absence of some kind of a global database (not necessarily X.500,
although
that is the most obvious candidate), there isn't very much that could be done to
prevent key reuse across CAs. Individual CAs could, and I would argue, SHOULD,
take
steps to prevent such reuse but this is a new requirement that we would have to
consider rather carefully. This also brings up some additional thoughts about
what
the purpose of the DN is in the certificate, and how it should be linked to the
directory entry itself, but I want to explore that in a separate message.
Now, you may want to indicate the issuer because you know something
about the recipient: you know that the recipient will trust your key
if it is certified by issuer A, but not by issuer B. So if I change
the key selector in transit, when the recipient goes to look up your
certificate in the X.500 directory, the trusted one won't be found.
Fair enough. But in this case I would ask this: What if there are
multiple people who will want to verify this message, some who trust
issuer A and some who trust issuer B? To me, this highlights a
confusion about what the Originator-ID is for. People are trying to
use it to convey certification information, when all it should do is
convey cryptographic keying information.
Well, I started to say that I agree, but now I am not so sure. This would imply
that the same key pair is certified by two different issuers, perhaps for very
legitimate reasons (the two CAs are part of two different PCA policy domains
which
partially overlap in their requirements/obligations.) So I agree with the need,
but
disagree with the implementation. Even neglecting the fact that different
algorithms might be involved, I would prefer that two different certificates be
used containing two different keys, which of course would require that two
different signatures be computed over the same message digest. Otherwise, there
is
confusion over which PCA policy was being satisfied by the (single) signature.
Likewise, to whatever extent the CA that issues the certificate shares some
responsibility/liability for its use/misuse, using the same key for certificates
issued by two CAs hopelessly confuses that responsibility, and therefore ought
not
to be tolerated, IMHO.
The right answer, IMHO, is to satisfy the different recipients by
putting *both* your certificate from issuer A and from certificate B
in an attached application/pemkey-data body part. And indicate these
by putting your public key in the Originator-ID field. This is what
I'm after by suggesting we only use the public key as an ID: not to
leave the recipient high and dry trying to use this as a database
index, but simply a pointer to the application/pem-keydata body part
where the recipient can select among any certificate that looks
trustworthy. "Oh, here's a certificate from Issuer A who I
recognize..."
I would differ slightly. There is certainly nothing wrong with including both
certificates in an attached application/pemkey-data body part, and until global
directories begin to proliferate this may be the preferred means of certificate
distribution. But this method should not be _required_. Both out of band and
directory look-up mechanisms should be supported. Using the issuer/certificate
number as the key selector allows the recipient to obtain the necessary
certification chain information from three places -- a global directory, where
the
certificates are filed under the originator's DN (or something derivable from
the
DN), from a directory that the CA might maintain, and from the recipient's
private
cache of certificates.
In summary, to me, the fact that one key may be certificate by
multiple issuers is one of the strongest arguments *in favor* of just
using the public key as the Originator-ID, because when you sign a
message, you never know which issuers each of the recipients will
trust and so you should not have to be forced to guess when you make
the Originator-ID (by putting in a key selector for only one of the
issuers). Instead, put any or all useful certs in the
application/pemkey-data that may be useful and let the recipient
decide.
In looking more into the potential deficiencies of MIME/PEM in the
infrastructure environment, the main one seems to be the inability to carry
an
originator's certificate in the message header (which 1421 supported).
While
this is not essential (as the recipient can always do a Directory retrieval)
it
could represent a substantial performance issue. Most other application
protocols which support digital signatures include provision for carrying
(at
least) one certificate along with the signature, so this looks like a
MIME/PEM
deficiency.
Reiterating: RFC 1421 forced you to choose only one of your
certificates to put in the Originator-Certificate field, even though
one of the recipients might want a different one (from a different
issuer). It is better to put the bag o' certificates in the
application/pemkey-data, letting the recipient's certificate chain
checking code decide which to use, and place the public key in the
Originator-ID as a pointer *only within the message* into the set of
certificates.
Warwick>You are now getting close to satisfying my residual concern, namely how
to
optionally carry originator certificate(s) with the message. I am afraid my
reading of the Draft did not give me the clear impression that
application/pemkey-data was intended to be used that way (although it does not
preclude that) - the document seems much more to suggest that
application/pemkey-data is a response to application/pemkey-request. If indeed
this is the intent, then I would request, at least, editorial changes which
state that application/pemkey-data can be used that way plus include an
example.
In fact, I would suggest it go further - state that use of an attached
application/pemkey-data is a "standard procedure" when originator
certificate(s)
is/are to be conveyed with a message. Without such statement, it is unlikely
interoperable implementations will result.
I would like to add the option of including the entire certificate chain or
multiple chains, not just the user's certificate in this case.
Bob