I have seriously considered the various alternatives that
people have suggested as to how to limit the potential
liability to a user, his organization, and/or his CA in the
event of the undetected theft or compromise of the user's
private key.
My conclusion is that for a variety of practical and business
reasons, it may not be possible to have a widely accepted
PCA adopt a policy statement that provides what I consider
adequate protection against a possible broad range of
liabilities.
Even if it were practical for the existing PCAs to adopt such
a policy, there are some arguments to the effect that a contract
between A and B is not binding on C. Whether this argument
would carry much weight, or whether having PCA-A publish user B's
intention as the equivalent of a Legal Notice in the newspaper
would have the intended effect is just not clear.
For a number of other reasons, I have to reject the idea that
the CA should publish its own policy. That would tend to make
every CA a PCA, and that doesn't "scale well."
I am therefore left with the conclusion that:
(1) some sort of a disclaimer is required for adequate
protection of the user, and
(2) the only place to put it where it will be both obvious
and firmly bound to the user's signature is in the
X.509 certificate itself.
I know that some, perhaps many, will disagree with me on
the grounds of cryptographic purity and/or political correctness
(tackiness), and I am sympathetic to those arguments, but the
X.509 certificate is the ONLY thing that a forger can't change
and still carry out the forgery, and therefore this is the only place
that a disclaimer can be guaranteed to be provided to the recipient.
(If he chooses not to read or head it, caveat emptor.)
I therefore recommend that the IETF or other appropriate organization
raise this as an urgent issue within the X.500 standards committee,
and try to get such a Disclaimer field added to X.509 at the earliest
opportunity. (Michael Roe's announcement of an opportunity to do just that
is very fortutitous.)
In the meantime, we are stuck with the current standard. I started to
say "and the current PEM implementations," but I realized that this
may have implications for PKCS, X.400 and other areas outside of
PEM as well.
Therefore, my present intention is to create two different CAs for GTE
Labs, both under a common PCA (probably the RSA Commercial Hierarchy).
One will be for use primarily within GTE for signing time cards and similar
intra-company business, as well as for routine email both inside and
outside GTE. The other CA would receive more limited use, would be
restricted to authorized user's equipped with smart card readers,
and would be intended for use in countersigning employee generated
documents, signing purchase orders, etc.
Since we will have two different CAs within one organization, we obviously
have to differentiate them at the level of the DN, and the only way to do so
that I am aware of is through the use of an Organizational Unit name.
I have seen similar OUs being used or proposed, such as RSA's
OU=Low-Assurance-CA.
On another issue, I previously raised the question of support for the X.509
1993 UniqueID field but got no response. I would like to encode the
employee's ID number in the certificate, both to guarantee uniqueness
in case we have two John Jones working for us and for adminstrative
convenience. Unless someone has a better idea, I plan to put that in an
OU field as well. (Might as well be really tacky.)
Because our official corporate name is awkwardly long for e-mail purposes
(GTE Laboratories Incorporated), we plan to register the shorter name
GTE Labs with ANSI, thereby avoiding the need for S=MA and the whole
issue of whether the S= indicates the statein which we are incorporated or
the state where business is being conducted, etc.
I am therefore planning to use something like the following for most of our
employees, but I want to be reasonably sure that this usage won't break
someone's implementation before I publish an internal practice:
C=US, O= GTE Labs,
OU=DISCLAIMER: AUTHORIZED COUNTERSIGNATURE REQUIRED,
OU=Employee # 22934,
CN=Robert R. Jueneman
I confess that I haven't paid all of the attention I should have to the precise
details of the ASN.1 encoding rules, etc. Is the colon in the OU=DISCLAIMER:
allowed? What about the # sign? I vaguely recall that OUs were limited to
either 26 or 40 characters. Is this a problem?
My goal is to make it possible to validate a user's certificate without having
to have a human read it, so I am not thrilled about having to encode a
disclaimer inside an OU field where it obviously doesn't belong. But at
least if everyone who needs this protection were to follow the convention
of OU=DISCLAIMER: blah blah blah, it would be possible to machine parse this
certificate as an exception without caring particularly what the disclaimer
says.
The user can then read the disclaimer in more detail.
I can hear the groans already, so if anyone has any suggestions I will be
happy to listen to them. But please, don't tell me that I don't or shouldn't
need to do this at all, unless you can make a positive suggestion how to limit
out liability in some other legally efficacious manner that our attorneys will
find acceptable. They're reasonably happy with this one.
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
1-617-466-2820
1-617-466-2603 FAX