Rhys,
I hope you will forgive me for posting your questions to pem-dev.
I'm sure that other users are facing the same problems.
------------------------
Bob>I gather from your comments that you are primarily
concerned with issues of privacy, rather than of
attribution/authentication.
Rhys>Well, yes and no. Privacy is certainly important out here in the
boondocks,
but I'm also concerned that I _have_ to get someone else to sign my key
before I can start talking in either a private or authenticated manner.
Except in cases of legal or commercial identity, this is not so important.
Although I know that RSA and TIS are operating PCAs, what is the point
of a rubber stamp allowing me to communicate? If someone questions my
identity on the net or I want to carry out legal or commercial transactions
on the net, then it is in my best interest to get my key signed by a reputable
source. But for casual communications, I see it as overkill. Even an
unsigned certificate could be useful on USENET to establish that messages
always come from the same anonymous source. I think I've even seen
some anonymous users signing their messages with PGP.
Related to this is the issue of DNs/ENs: what DN would I choose for
myself out here in Australia where it is likely to be years before the
requisite Australian PCAs are set up? The obvious one is something
related to my e-mail name. Should I make something up, or use a
standardised algorithm?
This doesn't quite compute. PCAs don't have anything to do with user's DN,
they merely sign CA certificates. Is your real problem the name subordination
requirement? If you, You'll get a lot of sympathy.
I have no idea whether there is the equivalent of the North American
Directory Forum for Australia, or who would eventually manage an X.500
directory. but you wouldn't go far wrong if you created DNs that followed the
usual organizational person style. the probability of an accidental
collision in the name space would seem to be very low. I don't see
any particular point of using your e-mail name as a DN, although if
we can change the format of X.509 it might be a useful attribute
to have in a certificate.
Bob>I'm not sure at this point whether you have a legal problem,
an administrative problem, or a technical one?
Rhys.Mainly technical (although there are potentional legal problems with the
RSA patent which doesn't apply here in Australia). There is nothing
that stops me generating an RSA key pair and using it for secure
communications: I just can't use it in the PEM style. But, I want to
support PEM in my UA software, rather than PGP, because PEM is
standards-track. But, my user population is at the disadvantage of not,
in the most part, being employees of big organisations that can afford
to set up CA's. This leaves me with a number of choices:
1. Find a PCA willing to set up an automatic responder to sign the
keys of the people who use my software. Or, at least find an e-mail
or postal address so I can tell my users, "Generate the key using menu
option X, then e-mail PUBKEY.DAT to pca(_at_)somewhere(_dot_)com, and send
a notarised letter to 'PCA, Somewhere Corp, USA', and then a few weeks
or months later you will be e-mailed back a signed key that can be used
to communicate". (See how silly this sounds to someone who just wants
to jump straight in and start using PEM?)
You have a point. The issue, of course, is whether you can trust
such a request when the user doesn't physically prsent himself in front of you
or your trusted agent. But maybe RSA or TIS would be willing to send you
the certificate via e-mail, then follow up with a mailed notice to your
postal address. If they don't get a reply within a certain period of time,
they might assume that a spoof was underway, and CRL your certificate.
2. Set up my own Persona PCA which simply rubber stamps my user's
certificates. I don't have facilities to do this, and what use is a
rubber stamp PCA anyway? If there is any likelihood that the IPRA (sp?)
will sign my top-level PCA key, then the whole CA structure goes out
the window as I am not willing to give any guarantees about the identity
of the people whose keys I sign. The only reason I'd sign them is to
hack around other PEM implementations that must have signed keys.
This doesn't seem so bad. If there is no infrastructure available
to support a reasonably high level of confidence in the binding between
the user's name and his public key, you are just running a Persona CA
in any case. On the other hand, if you don't mind having to swear before
a Notary Public that you are who you say you are, having one of
the US or other PCAs sign your certificate is just a matter of the mail
transit time.
3. Break the PEM certificate format so that self-signed certificates are
permitted, with the option of the user being able to get their key signed
if they feel the need to do so. Either that or only support RIPEM which
was really just a hack arising from the certificate formats which did not
support e-mail addresses or non-signed keys.
This might actually have some real merit, although it might break a number of
PEM implementations. At worst, an implementation should say,
"This certificate is signed by the user himself ?!#(_at_)!" If and when the
user receives a "real" certificate signed by a real CA, he can distribute the
new one. Until then, the self-signed certificate would not have a current]
CRL, either, so PEM will object to that as well.
If some kind of convention is adopted for allowing self-signed certificates,
then the CA hierarchy can grow from the bottom up: as more and more users
make use of PEM, there will be more incentive for admins to set up CAs.
Take my e-mail address (rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au) for
example: if lots of people
wanted to use PEM here, then the admins could set up a CA for the
fit.qut.edu.au domain, giving an extra level of assurance as to our
identities. Then, the admins of qut.edu.au could sign the keys of all
the subdomains, and so on up to "au" which would be administered by
the Australian domain co-ordinator. If the IPRA signs this top-level
domain key, then the whole hierarchy joins up, with validation immediately
for everyone below it. But, if we have to wait for all of the domain admins
to set up CA's first, we'll be here forever. Note that this argument
equally applies if we use more conventional DNs rather than e-mail
addresses, since corporate structures are very similar to the domain
name system.
No, this doesn't quite work. Adding support for an increasing number of CAs
would simply require that more users directly enter the public keys
of the CAs they trust into their cache of trusted keys.
I also don't see the need for the Australian domain coordinator to sign the
keys for the subdomains. Are you confusing naming authorities with
PCAs?
It seems preferable for you to use one of the existing PCAs to co-issue
certificates on behalf of your CAs, until a PCA can be set up in Australia.
And I would also think that you could use residential person certificates
issued by RSA or TIS to get over the initial hump.
The more I see people telling me to "contact RSA or TIS", the more I
feel that getting a key signed is a "tax" on the use of public key systems.
That people who don't want to do that are "scum" or "tax-avoiders"
and do not deserve to communicate in a secure manner. Why should
anyone trust my key just because it has been signed by RSA? They would
have greater confidence if it was signed by my local domain admin, but
my local admin is not going to set up a CA until a sizeable number of
people start using PEM. Catch-22.
Well, there is a certain amount of truth to that. RSA holds the licenses
and has done a lot of work in trying to set up this system -- they are
probably entitled to a certain return on their investment. And as you
point out, there is a considerable amount of sophistication involved in
setting up a PCA, what with the IPRA registration and all of the CRL
administration.
"Why should anyone trust my key just becasue it has been signed by RSA?"
Excellent question. Presumably it is because the users have read RSA's
policy statement as to the degree of care and evidence they will require
before issuing a certificate. At a minimum, other users will try to track
what the various PCAs do, and blow the whistle if anything goes too far
wrong. Ultimately it would be nice to have some sort of a user's group that
would have a sufficient amount of clout to demand periodic audits, etc.,
a la Underwriter's Lab or the major accounting firms.
But I think you have hit the nail on the head. Except possibly for the most
enlightened corporations, CAs are not going to be established until there
is a sufficient user population within that corporation to justify it. And
without an easy to use means of getting certificates signed (i.e., through
your local CA), there won't be that degree of use.
I'll add one more concern. Those user's who stop to think what their
potential liability might be for a digitally signed message will want
to check this possiblity with their corporate lawyers, and the issue
will come to a screeching halt at that time, at least within the litigious US.
Cheers,
Rhys.
G'day, mate!
Bob