Warwick,
today's random rumbling:
if a V3 certificate contains a DN (it has to, if it is to be looked up
in the directory), a DNS name, an EDI party name, and an rfc822 name,
what assertion does the signer of the certificate make about those
four names, or those four named objects?
That they are the same?
That the named entities all possess the same secret key, but the
relationship between them is otherwise unspecified?
That you must read the CA's policy document to find out what it asserts?
I *think* I like V3 certificates, with or without attachment to an
X.500 directory, but I'd like to know who gets to define semantics.
Harald A
Harald, those are really good questions.
My operating assumption has been that these are effectively aliases of a common
user's name/identity, but this might not be the case. For example, it isn't
clear that an rfc822 name represents a singular entity -- it might be a shared
mailbox or distribution list, and you shouldn't necessarily assume a one-to-one
correspondence with that mailbox name and a particular key. Likewise, an EDI
party name might apply to an organization collectively, not to the individual
purchasing agents or users, etc. And I don't know what a DNS name implies. In
general, it appears that the scope of these names may overlap in rather strange
ways., i.e., may not be globally unambiguous and equivalent to the unique
individual identified by a DN (regardless of what kind of a DN is used).
Your point about who specifies the semantics of these names and their
association in a certificate is also very important. What is being asserted
with respect to each of these names or other attributes, and how does the
relying party know that?
There has been some discussion of those issues within the ABA Information
Security committee, and although the ink isn't dry yet, let me try to give you
the flavor of the thinking.
In the best of all worlds, the relying party (anyone who examines a digitally
signed document together with a certificate chain) would like for the
Certification Authority to be omniscient, infallible, and possessed of very
deep pockets in the event that the relying party accepts the representations
made by the CA and suffers harm because of some misrepresentation, even if the
misrepresentation was the fault of the subscriber.
Unfortunately, this isn't a "commercially reasonable" assumption to make,
especially if certificates may be used for multiple purposes. Unless an
exorbitant fee is charged for issuing the certificate, the CA cannot possibly
act as an private investigator and determine the validity of every
representation made by the subscriber.
One approach to this problem is to minimize the information content of the
certificate to that which a CA _can_ confirm, at least to a reasonable
(affordable) level of certainty. For example, the CA may not be able to confirm
the subscriber's "real" name (whatever that is), but the CA could confirm that
the person who claims that name is employed by a particular organization. Or
that the person's observable characteristics (height, weight, color of skin,
hair, and eyes, and perhaps a fingerprint) are as advertised in the
certificate. But the CA may have to take on faith the user's claimed e-mail
address, etc.
In the case of a closed group of users, all of whom are following the same
policy and rules, this won't be much of a problem. But if we want to support a
more open framework it is necessary to know which attributes have been verified
by the CA and which have not. And although it may be necessary to go read the
CA's policy to determine the precise criteria used to validate the information
that the CA does represent as accurate, it would be desirable to have an
explicit indicator of any nonverified subscriber information which the CA is
including at the request of the subscriber but has not independently verified.
In addition, although X.509 V3 defined a mechanism for marking certain
attributes as critical, primarily the path constrints, the authors of the PDAM
did not consider the possibility that other extensions might also need to be
marked as critical, including issuerDirectoryAttributes.
I have therefore proposed the following to Warwick Ford, the primary author of
the X.509 v3 and the PDAM. We have had an extended discussion of these issues,
but have not yet reached closure regarding the inclusion of these fields in the
"official" ISO extensions list. Of course, if ISO doesn't include them in their
approved list of attributes a la X.520 it won't be the first time that has
happened, and the IETF or even indivdual implementors could register and
implement these extensions themselves.
The five new extension attributes I have proposed for X.509 v3 are:
criticalSubjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax IDENTIFIED BY ( id-ce x )
-- This extension is always critical. }
issuerDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax IDENTIFIED BY ( id-ce y )
-- This extension is always noncritical. }
criticalIssuerDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax IDENTIFIED BY ( id-ce z )
-- This extension is always critical. }
nonverifiedSubjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax IDENTIFIED BY ( id-ce v )
-- This extension is always noncritical.
-- The attributes listed in this extension are supplied by
-- and their accuracy/applicability sworn to by the subject,
-- but merely witnessed, not independently verified, by the
-- CA.}
I'm having a hard time imagining what kind of subject attributes would be not
be verified by the CA but would nonetheless be considered critical by the
subscriber, but I suppose one could exist. Maybe one example would be a
subscriber disclaimer. The winner for the longest attribute name is therefore:
nonverifiedCriticalSubjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax IDENTIFIED BY ( id-ce w }
-- This extension is always critical.
-- The attributes listed in this extension are supplied by
-- and their accuracy/applicability sworn to by the subject,
-- but merely witnessed, not independently verified, by the
-- CA.}
By implication, any attributes other than those listed in the two nonverified
extensions would be considered verified by the CA. So far, I haven't thought of
any reason why there would be any need for a
nonverifiedIssuerDirectoryAttributes extension, much less a
nonverifiedCriticalIssuerDirectoryAttributes extension -- it doesn't make any
sense.
In addition to marking certain attributes as critical and/or nonverified, it
would certainly be desirable if a relying party could quickly and easily access
the CA's policy if required. Unfortunately we cannot necessarily assume that
all CAs will register under the IPRA's umbrella, so we may not know where to
find the policy.
In addition, if a dispute arises with respect to an archived document, it may
be relevant to determine exactly what representations were made by the CA (1)
at the time the certificate was issued, (2) at the time the document was
signed, and (3) what representations were still in effect at the time the
relying party made his or her decision to rely on the certificate. In other
words, we need norepudiation of the CA's policy.
The current PDAM defines an OID mechanism that can be used to reference a
policy and require that subordinate CAs conform to that policy and include that
OID in their certificates, but there is nothing specified, much less enforced,
that would require a new OID for every revision of the policy. Indeed, if the
OID is used to represent the overall policy of some industry, it isn't at all
cear that the OID _should_ be updated every time a minor change is made, for
that might invalidate all of the certificates issued under that the broad
umnbrella of that policy.
Finally, it isn't sufficient to merely provide a pointer to the policy
statement, for that policy might not be signed and could easily be changed. In
fact, without a trusted time stamp or other such mechanism, the CA could simply
modify the policy and sign the revised version, and no one would be the wiser.
For that reason, I believe that we need three additional
issuerSubjectAttrributes. We can decide on the attribute names and precise
syntax later, but the first attribute should be a brief (less than 1000 bytes)
disclaimer statement which synopsizes the policy limitations. The second should
basically be a URL type of mechanism (or an X.500 DN for a document) which
would point to the CA's policy, and the third should be the digital signature
of the policy, or at least the message digest of the policy.
(The second and third attributes could of course be combined into one compound
attribute, but I hate to invent new compound attributes because of the impact
on existing and future user agents that have to understand the new syntax.)
My tentative thought was to describe the CA's policy as a MOSS object, and I
would welcome a contribution by Ned Freed or someone else as to what the ASN.1
should look like for such a policy reference.
Bob
--------------------------------
"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>
Staff Scientist, Wireless and Secure Systems Laboratory
GTE Laboratories, 40 Sylvan Road, Waltham, MA 02254
Waltham office: Voice: 1-617-466-2820, FAX: 1-617-466-2603
Telecommuting: Voice: 1-508-264-0485, FAX: 1-508-264-4165