In a previous message, Peter Williams asked:
3 points bob:
(a) do you consider the RFC COST and RSA Commercial Hierarchy operating
commercially ?
Yes and no. Without denigrating those efforts at all, I believe they are
essentially pilot projects. Perhaps you could answer a couple of questions --
how many certificates have been issued to date, and when does Verisign envision
becoming profitable with regard to these operations?
do you consider the several thousand Netscape merchants (with v1 server
certs) commercial users?
No, not really. Not in the sense that I was using the term, for to the best of
my knowledge those merchants are not yet digitally signing anything. They are
using certificate to facilitate offering privacy to their customers,
presumably, but I don't think of them as using them for purposes of trade under
the UCC. Not yet, anyway. (CyberCash's system might be an exception, and there
may be a small handful of others). It's when they start accepting
responsibility for doing something by using their digital signature that the
issues of merchant and CA liability will hit home.
I don't know where to draw the line, or whether it is all that important, but I
would think that a million merchants and 50 million certificate holders would
be the scale of "commercial" operation I have in mind. Would a thousand
merchants and a million certificate holders be a heck of a good start?
Absolutely. The point is that numbers on that scale force you to think about a
lot of things that might not otherwise be addressed, such as how you are going
to do certificate distribution, how you are going to validate all those
identities (if you do), how to revoke and archive certificates, etc.
(b) I'm after discussion of the countermeasures involved in 1422, rather
than its concept of operations for PEM. Particularly, the minimisation of CA
masquerade damage. As chains become required to fanout operating authority,
controls have to be enforced for real, not on paper. CA administrators are
going to make exceedingly bad policy enforcement instruments, I fear.
I think I missed your point earlier, perhaps because I have been focussing too
much on the problem of issuing certificates to the residential consumer, not to
the organizational person.
Certainly it is extremely important to minimize the possibility of CA
masquerade. There would appear to be two problems:
1. Someone attempts to impersonate a legitimate top-level CA, whether the
IPRA, the MasterCard International root CA, or the RSA Commercial Hierarchy,
and
2. A lower-level CA( in a chain that is headed by a valid and trusted root
CA) that issues certificates in violation of its own policy and the terms of
the agree-upon policy established by the root CA (PCA, in PEM terminology).
In retrospect, embedding the key of a top-level CA in the code, as Apple did in
their first release, is almost surely NOT the way to do to solve the first
problem. First of all, it makes the system quite inflexible, as you have to
change the code in order to change the policy or rearrange/rename the
hierarchy. Secondly, and more important, it requires making the vendor part of
the trust model, and they surely shouldn't be. Otherwise it is too easy for
Mafia Programming, Unlimited, to set up their own CA which pretends to be
someone else.
Although the root key of a hierarchy itself does not necessaily have to be
distributed out of band , in particular non-electronically, it is crucially
important that the validity of that key be confirmed by non-spoofable means. I
think that it is unfortunate that the Visa/Microsfot STT spec doesn't address
this critical issue.
The approach taken in the MasterCard SEPP spec is to allow the user to obtain
the root key by any of a number of different means, including bundling with the
vendor software (as an .INI type file, not hard-coded), from the MasterCard
home page, via e-mail, and/or downloaded during the user's certificate request
processing. But we require that the user enter the hash of the root key for
verification before being issued a certificate. This hash would be provided in
statement stuffers, in national advertisements, etc., to make it very widely
available.
It is admittedly an inconvenience to force the cardholder to go though this
step, but if the root key is wrong the entire system could conceivably
collapse. Of course, once the user starts interacting with merchants and
acquiring banks that validate her certificate, any discrepancy in the root
certificate would be discovered fairly quickly -- presumably the attacker can't
take over all of the merchants in the world simultaneously, nor divert the
customer's traffic to one particular phony merchant for too long, so the window
of opportunity is fairly short. This also provides a certain amount of
protection against the surreptitious replacement of the public key of the root
CA in the user's own computer, although that key should be protected at least
as well as the user's own private key.
One last point. Because the possibility of a compromise of the root key cannot
be ruled out absolutely, the system design has to first of all minimize that
possibility as much as possible, and secondly has to provide a means of
distributing a new root key on an emergency basis.
There were two primary reasons for architecting the SEPP CA hierarchy as three
tiers, with the possibility of growing to a fourth. Because on-line CAs were
required in order to meet the throughput and response time requirements for
certificate generation, we knew that we would have to change those keys fairly
frequently. For one thing, we wanted to limit the number of eggs in a
particular basket, so that one key wouldn't be used to potentilly process
millions of dollars of transactions -- it would make it too attractive a
target. And the other reason is that affordable, very-highly secure trusted
computing systems are simply not readily available. Firewalls and the usual
kinds of even A1 systems are almost useless when your object is to attract
people into your system, not to keep them out! So we had to face the
possibility that the software used to control the issuance of the certificates
might be compromised. If that were to happen, it would be necessary to revoke
all of the suspect certificates, i.e., those issued back to a known-good system
checkpoint. Since we couldn't trust the issuance date in any compromised
certificate, it was necessary to have a rather short cryptoperiod. what that
period will be hasn't been decided, but it is more likely to be on the order of
days to weeks than hours or months.
Assuming the lowest level CAs need to change keys every day or so, it is
obvious that this would require too much operational exposure of the cryptounit
used to generate these keys if there were only a two-tier hierarchy. In
addition, we recognized that the laws in various countries might require
slightly different policies, including key escrow or similar requirements in
some countries but not in others. We wanted to contain such differences as much
as possible, and so the concept of a country-level CA in between the
operational CAs and the root was created. Assuming that the root CA and the
country-level CAs are both implemented in highly secure, totally off-line
processors, it should be reasonable to establish cryptoperiods for the
country-level CA keys that are in the range of a year to five years, depending
on the amount of activity.
Asumming that the root CA's key is protected and physically distributed to
multiple sites using secret-sharing techniques, that key should be considered
valid until revoked. The processes used to protect the key must resist both
physical attack and even kidnapping/terrorist attacks, to the point were it
would be physically impossible to cause a compromise without requiring at least
a one to two day delay. This implies that the encrypted, secret-shared portions
of the private key of the root should be stored in bank vaults in several
different cities, under the signature and key control of senior executives.
Generating a new country-level CA should then require these executives to
retrieve they key token from the vault, and then travel to a central site where
the key parts would be reconstituted within the tamper-proof cryptounit. As
soon as the necessary certificates are generated, the secret key is again
divided into multiple encrypted parts and given back to the executives. The
window of opportunity is therefore quite short -- on the order of an hour once
a year or so.
The reason I said that the CA hierarchy might grow to four levels would be if
there were other payment associations that wanted to piggly-back on the
MasterCard infrastructure. In the case of very large payment association, e.g.,
Visa or American Express, that might not be too wise -- too many very large
eggs in one basket. But in the case of some of the smaller associations,
perhaps including EuroPay, Discover, Diner's Club, etc., it may be desirable to
use the MasterCard International CA as a sort of super-root, and cross-certify
the EuroPay, etc. three-tier hierarchy as though it were a country-level CA.
Individual banks that wanted to act as their own certificate issuers for some
reason could be handled the same way.
Nonetheless, if nothing can possibly go wrong, nothing will go wrong until the
worst possible moment for a disaster to happen. The one thing that you do NOT
want to do in that case is to use the existing root key to validate a new root
certificate, because it would be cryptographically imposible to distinguish
between a certificate that was signed before the secret key was compromised and
one that was compromised later. So chaining root keys together should be an
absolute no-no.
In addition, unless the replacement root keys were all pregenerated and stored,
one possible reason for having to replace the root key is because the private
key has somehow been destroyed, rather than compromised. But if all the
replacement certificates are pregenerated and stored, why not go ahead and
distribute them along with the first root key? Then the entire collection of
certificates could be authenticated with a hash check.
The Microsoft/Visa STT spec includes an Emergency message that can be used to
support global root key replacement, and they argue that requiring the new root
to be signed by the old one prevents denial of service attacks. That it would
do, but it might also prevent the root key replacement! They do use the concept
of validating the new root by typing in the hash obtained from the Microsoft
800 support number (that ought to cause denial of service to all of the
Northwest, if everyone calls them all at once!), or a trusted source such as a
newspaper ad. Strangely, they don't describe this approach in their initial
distribution of the CA key.
My view would be that if the root CA key has to change for other than a
preplanned reason (in which case new root keys can be distributed in advance,
when the cardholder renews his certificate every n years), then the cardholder
is eventually going to need a new certificate in any case, and so the new root
key can be distributed by the Certificate Management Server in the same way it
was to begin with.
I am absolutely certain that if a root key compromise were to occur the news
media would have a field day, and there is little chance that people wouldn't
hear of the problem. The denial of service attack therefore seems rather
improbable.
Its also important to note that a compromise of the root key doesn't
necessarily invalidate or compromise all of the existing lower level CA,
merchant, or user certificates -- it just increases the risk that a new, bogus
CA could be created. Since at present the cardholder receives the certificate
of the acquirer from the merchant, and the merchant gets a fresh, up to date
copy of the acquirer's certificates every day, there are alternate ways of
distributing known good certificates.
Although these issues certainly need to be thought through carefully as part of
a contingency plan, the most important point is to avoid causing more harm than
good in the event of a compromise. Blasting out an emergency message telling
everyone in the world to change their root keys might do more harm to the
global economy than quitely suffering through some losses until an appropriate
and eliberate solution can be found.
The issue of CA policy enforcement, my second point a couple of hundred lines
ago, is very important, as is your discussion of certificate formats and
liability paradigms, but this message is already way too long. I'll respond to
those points in separate messages.
Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting