Bob writes:
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.
No worries.
[I've reformatted Bob's reply slightly so that his and my comments are
a little clearer - I will never get used to this "Name> paragraph"
quoting style. :-)]
Bob: >, >>>
Rhys: >>
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.
Just a slip. Whether we're arguing about PCA's or CA's, it will still be a
long time before any kind of signing service exists in Australia which is
large enough and respected enough to be useful. Name subordination is
certainly a problem, but a fairly minor one from one viewpoint.
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.
I can't see why an e-mail address can't be turned into a DN, if the user
so chooses. It _is_ the most obvious naming scheme for the Internet and
there already exists a distributed naming authority for allocating chunks
of the namespace. Until I actually see X.500 deployed widely in my
life-time, I will remain skeptical about its potentional.
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.
Still, what is the turn-around time? A week? A month? Two months?
If I want to communicate casually, I want to do it _now_ and then add
the extra layers of authentication when I need them. If your whole
concern is the lack of a CRL mechanism for casual keys, then I think
you've missed the point: we should be concentrating on getting people
to generate keys in the first place, rather than how to eliminate
existing keys.
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.
Wait till you hear version 2.0 of this idea that I thought up last night. :-)
Since I don't have the resources to set up a dedicated "rubber-stamp CA",
and the only reason I'm signing a user's certificate is to get around PEM's
requirement that a key must be signed by someone else with a parent DN,
I might as well distribute the private key for my CA with my software and
the user can generate and sign their key with no fuss. This is the
ultimate rubber stamp. I wonder how long people would trust the CA system
(not just my subset, but all of it) if authors started doing this? The best
option in my opinion is to give authors an alternative where they don't
need to resort to such measures to make PEM work, and so that real CA
signing doesn't lose its value.
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.
And my question is, in light of "Rubber-Stamp CA Version 2.0" (RSC2) above,
what use is a Persona CA anyway? If there isn't a reasonably high level of
confidence in the binding, there is no point to get a signature anyway:
the user might as well sign it themselves. The only problem is that of
name duplication: a Persona CA (from memory) is supposed to make sure that
the DN's on all keys signed are unique. With no signing, or RSC2 signing,
there isn't this guarantee, but if we have a convention whereby the DN
is based on the e-mail name in some way, at least the user can choose a
DN which is guaranteed to be unique by existing Internet naming authorities.
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.
OK. Will you, or anyone, tell me the following: where exactly can I e-mail
or postal mail information sufficient to get a key signed? I'd like to
know. I haven't seen any such information on this list, except maybe for
"if you use our software, we'll sign your CA key". If I can get such
information, I'll be happy to include it in my documentation for my users.
But, it must be an option for my users to do this, not a necessity, or
they will pound on my mailbox with hundreds of messages saying, "why don't
you use PGP instead of this 'call RSA and convince them you exist' rubbish?".
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.
Until X.500 is widely deployed, CRL's are going to be almost impossible to
get anyway, so there already are problems.
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?
Since the DNS already exists as an established naming authority, it is the
most obvious way to set up an Internet CA system, and would be a very
simple extension of a domain coordinator's normal duties. It is by no means
the only way, and others are more than welcome to set up CA systems based on
"user friendly" names. The more the merrier.
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.
But ... what I am trying to get across is that I don't see why we need
to _require_ CA's!! They serve a useful purpose to establish that a name
really, truly, is bound to a particular private key, as identified by the
public key in the certificate. But, the real world doesn't require
people to be authenticated entirely before most forms of communication
take place. If I meet you on the street, I don't need to see your driver's
license to talk about the weather, sport, etc. If we were carrying out
some kind of legal or commercial transaction, it may be necessary. Even
most financial transactions happen with absolutely no reference to identity:
supermarkets, street stalls, newsagents, etc. There certainly are some
things where identity is paramount and for those it is prudent to get extra
authentication. But, until such time as I need such authentication,
why am I required to get it for everything else as well?
"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.
*snort* You really expect the majority of PEM users to read the RSA policy
statement? You expect them to understand all that legal mumbo-jumbo? :-)
As an aside: organisations such as the EFF would probably take on the
watch-dog role as part of their normal duties, so that issue is already
taken care of.
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.
Precisely. Which is why we need to break the loop: adopt a method which
allows use of PEM to mushroom to the point where the users themselves start
wanting CA's. RIPEM has such a method, and if that is judged the best
way to do casual PEM use, then _please_, someone, anyone, write it up in
an Internet Draft so that I feel confident implementing it. If self-signed
certificates are judged the best, then the same applies: write it up!!
Heck, I'd volunteer to do it myself if I was confident that the PEM working
group wouldn't accord my Draft a status of "this guy is a nut, no one in
their right mind would implement such a scheme" and prevent it from getting
to RFC status.
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.
Which is one more reason why we need a CA-less certificate format, so we
can say "there are no guarantees whatsoever for messages signed with
such a certificate, unless other arrangements have been made (e.g. a key
transported in a briefcase hand-cuffed to a courier's wrist)". So, the
default in users minds is is "trust signed messages at your peril", rather
than "if the key was signed by someone else, it must be good".
Cheers,
Rhys.