Let me see if I can synthesize some sort of common ground from
some of the recent comments.
I'll put aside for the moment Bob Smart's questions about who the
CA should be for an e-mail address-based PCA hierarchy, and come
back to it later.
I didn't hear any violent disagreement with my observation that
we already have most if not all of the tools necessary to support
Bob Smart's (and Christian Huitema's) observations regarding the
desirability of having anonymity sometimes, moderate disclosure
of identity details for casual use (e.g., e-mail addresses), and
moderately full disclosure (organizational DNs) for some purposes,
especially commercial transactions or messages.
I certainly accept the desirability of each of those separate goals,
and would urge the creation of appropriate PCA hierarchies to support
them as necessary.
I think that the RSA Persona PCA supports the first (anonymity) quite well,
and I haven't heard any complaints about the system being too hard to
use, etc. (I also haven't seen or heard of anyone using it yet, either.
Maybe there isn't as much need as we thought?) Assuming that name
subordination is used, so that we don't have to go to the IPRA to
resolve Persona name conflicts, I have no problem with going to TIS,
COST, or any other PCA provider for such a service. But since this
mechanism exists and seems to be workable, why don't we try using it
before we decide that we need something else?
I think we have to do a little work to create the right kind of attributes
for an e-mail address-based DN, but Steve Dusse seems to be moving
quite rapidly to set up such a PCA, which would presumably operate
via an automatic responder and would mail the certificate back to the
requestor without requiring any proof of right to use other than
successful delivery of the certificate.
(I don't recommend it, because I believe that it would make the
international use of X.500 quite cumbersome, but if someone wanted to
badly enough I suppose that the e-mail name itself (not just the attribute)
could be registered under the Internet arc { iso(1) identifiedOrganization(3)
dod(6) internet(1) }, and would not even require a Country= qualification.
It would still be a DN, and separating the components into domainNames
might facilitate X.500 searching, but this could be hidden from the user.)
Finally, we have the RSA Commercial Hierarchy (and others) who are
up and running and issuing certificates to residential users under their
own CA, and are also issuing CA certificates to CAs as they join. Admittedly,
the effort of getting one's organization to sign a contract with RSA,
receving and installing a SafKeyPer box to issue keys, and establishing
the infrastructure necessary to control this process is a substantial
effort, as I can attest. But a number of large companies have already done
that and the process is becoming smoother over time.
In addition to the RSA Commercial Hierarchy, which has rather stringent
controls as befits a PCA whose policy is intended to support commercial use,
TIS also operates a PCA, and their requirements as to establishing
prrof of right to use the corporate name are much less stringent. Likewise,
RSA operates a Low Assurance hierarchy which is intended for testing,
and does not require a SafekeyPer box or any proof of right to use the name.
Since an adequate number of PCAs seem to be in place, and since it
is presumably easy for users to generate their own prototype certificates,
the major difficulty would appear to be the establishment of a CA
within the user's organizations that can issue a "proper," i.e.,
civil name subordinated certificate.
This problem can also be solved by having RSA act as a co-issuer, but
it does still require a contract be signed and an "organizational notary"
created to process and authenticate certificate requests.
If we can agree that the establishment of organizational CAs is the primary
problem, then we can probably make some progress.
There would appear to be two alternatives:
1. Let users create and sign their own certificates, just as they do in the
certificate request process anyway. Let the users go ahead and ship those
self-signed certificates along with their messages, and confirm their validity
through out of band means.
2. Create a low assurance CA that will sign the user's certificate little, if
any requirement as to proof of right to use the organizational name.
The first approach requires some tinkering with the existing implementations,
so that certificates that are not validated by a CA and a PCA , dont have
a CRL avilable, etc., are not automaticaly rejected, but rather the user
is allowed to act as his own IPRA as it were, and validate whatever tree
or subtree he likes. Assuming that out of band confirmation really is
used, this approach does provide at least as much trust as any other,
and perhaps more than some.
The second approach has the advantage that it fits within the existing
architecture and implementations better, but it conveys a false sense
of security unless the CA asks at least a few good questions.
Now back to Bob Smart's issue regarding who should certify an
e-mail address based certificate:
What should the CAs be under this PCA? There is an obvious answer which
does not seem to be inconsistent with anything you have said: The CA
should be the domain in which the e-mail address appears.
Now if the relation between the public key and the e-mail address
is certified by the owner of the domain of which the e-mail address
is a part then there will be a very HIGH level of assurance about the
fact that the e-mail address goes with the public key.
If by contrast you use a responder CA like RSA's proposed service the
level of assurance can never be more than medium. If a CA wanted to
add e-mail attributes to a DN: how would it do it with high assurance?
I guess it would check with the owner of the domain. But in that case
isn't it better for the owner of the domain to sign the certificate?
Yes, I suppose that if I could get my local network administrator to act
as my CA, he or she would be in a good position to know that a given
mailbox exists. And they might or might not know whether I have the
exclusive use of the logon ID and password.
But these people, or people very much like them, are the same people
that will probably be issuing certificates if and when a "real" organizational
CA is set up. So this really doesn't help, it simply perpetuates the problem
by changing its name.
I would argue that if an organization hasn't set up the appropriate controls
to run an organizational CA, it has no business trying to run an e-mail CA
either. It is the physical and procedural controls that make a medium or
high level of assurance identity meaningful, so until those processes are
in place we might as well accept a low assurance solution.
Basing a low assurance certificate on the validity of the return path
is not all that bad. If the certificate doesn't arrive, then probably the
path wasn't valid or the mailbox didn't exist. Even though it would be
pretty easy to spoof a mail system temporarily, some addition protection
could be provided if the e-mail CA were to send a confirmation message
of the sort, "We recently sent you the following certificate. If you feel
that this was sent in error or you did not request it, please call us."
In summary, I think we have four problems that we are trying to solve:
1. Creating medium to high assurance CAs is an inherently difficult
process, primarily because of the need to institute good procedural
controls.This will take time, and needs to be done right for the long term
benefit. We shouldn't compromise this process.
2. For unknown reasons, users have been slow to take advantage of
existing PCAs and CAs for Persona certificates, which could certainly
contain an individual's e-mail address as the common name. If a message
is received with such a certificate from a different e-mail address, some
eyebrows would probably be lifted.
3. The IPRA has been exasperatingly slow to come into existance. In
addition, existing implementations haven't been very flexible in allowing
the user to specify which PCA certificates (multiple ones, at least until
the IPRA is working) are to be considered valid.
4. There are some human factors issues having to do with how
to glue together a mailer and a PEM implementation in the absense
of X.500, and perhaps some less than adroit implementations that make
user type too much. The use of e-mail address in certificates has been
proposed to solve this problem, and it may appeal to people who are
never going to like DNs in any form. But although these issues might
be quite annoying, I really don't believe that they are show-stoppers.
My recommendation to the WG would be the following:
1. Stop relying on volunteers to bring the IPRA into existance. I'm still
not absolutely convinced that the IPRA is needed, but if it is, then
issue a contract to someone to do it, do it right, and get it done right now.
I don't know who has this responsibility, but this is ridiculous.
2. Fix the existing implementations so that they can operate with tunable
filters and not require CRLs, CA-signed certificates, PCAs, etc., if that's
what the use wants. Instead, allow the user to specify the public keys
or certificates of anyone and everyone that he or she trusts, whether
an individual, a CA, or a PCA. I don't think it takes an RFC to specify
this -- it is an implementation problem of how to specify the root key or
keys for a hierarchy. This is perhaps the most pressing problem we have.
3. Presumably there are implementations out there that are at least
tolerable and capable of generating public keys and certificate
requests (if not, then all the argument over architecture is moot). So
strongly encourage those users who are complaining about not being
to get a CA to sign their certificates to create Persona certificates
containing their e-mail name in the commonName field, send them
to RSA and get them signed, and then put them to use.
4. Encourage PEM implementors to make their packages small and
portable across operating systems, even if they have to give up
integration with a mailer. Whatever mailer they choose, the user will
probably want something different anyway, so we can probably
wait for Eudora and ccmail and Lotus Notes, etc. to do this integration
into their packages for us. I believe that the cumbersomeness of the
existing Unix implementation is at the heart of the current difficulties
we have. If we had a decent Windows or Mac solution, or even
DOS (as RIPEM does), we would have lots more users.
I remain convinced that we can solve these problems within the
existing architecture, and feel that splintering the efforts into two
working groups would be a huge mistake.
Bob