On Tue, 15 Mar 1994 jueneman%wotan(_at_)gte(_dot_)com wrote:
I'm in the process of writing a "CA Guidelines for
Name Registration" document as part of the ABA
committee I am working with. I hadn't specifically
planned to do so, but with a little editing I could
probably submit this as an Internet draft or RFC,
if you think that would be of any help.
Definitely. For PEM use, most implementors and authorities will go to the
RFC's first to find guidelines, so a copy should be available there.
The NADF standing documents [...]
I will look them up.
But these are nice problems to have to solve, after an
organization has made a decision to go forward on such a
basis. In the meantime, you may want to just pick a name
and try using it.
I suppose I shouldn't be using the QUT example to get across my main
point. QUT already has an established organisation name and I can't go
too far wrong, unless the powers that be got out of the wrong side of the
bed the day they find out about it. :-)
A better example of where organisation names aren't all that good is in
the public access sector. As I've stated previously, I'm the president of
BrisNet, the local low-cost UUCP/IP provider. Now, we could set up a CA
with names like:
C=AU, S=Queensland, O=BrisNet, associationNumber="ACN ???/???",
CN="Fred Nyerk"
But, this is a burden on a network that is otherwise run by volunteers.
BrisNet's organisation name is more for tax purposes than anything else.
You now put up your hand and say "Persona CA", but the BrisNet members
then put up their hands and say "What the hell is a Persona CA?". :-) The
whole "try before you buy" comes in here too with self-signed
certificates. If the BrisNet members wanted to use self-signed
certificates, what address would they use? Make one up and probably get
the legally required structure above wrong? Use the RSA Persona hierarchy
but sign it themselves? Residential hierarchies with the risks of
exposing a home address to the whole world? Something else? This is what
I'm getting at with the DC/RM proposal. Sometimes it is simply not
possible to choose a good traditional DN. For those cases, some
translation of the e-mail address is warranted I feel.
Until there are decent guidelines for naming all those people who occupy
the cracks between organisations, something else is needed, and soon.
1. It's free.
3. It's free.
5. It's free.
7. It's free.
9. It's free!
:-)
Your only problem would seem to be that you will have to
scan for the RM, rather than having a specific attribute
jump out at you, but that is the price you pay for the
convenience of not having to change PEM (or X.500).
Are we going for convenience here or a scheme that will cause the biggest
explosion in the PEM user base?
Finally, I will describe "What Rhys dreams about when he thinks about the
user key generation process". :-) Ultimately, for casual use PEM, I'd
like key generation to happen thusly: the user would type in their name
and e-mail address and hey presto, instant self-signed key. I'm looking
into how traditional DN's can be made this easy, but am a little
skeptical at present. Keep in mind that most PEM users will be ignorant
of what X.500 is so there will be quite a lot of hand-holding required.
Cheers,
Rhys.