On Fri, 11 Mar 1994 jueneman%wotan(_at_)gte(_dot_)com wrote:
1. The user's common name should be used in addition, to
qualify the mailbox name.
Both of my major proposals allow this. The only modification is that I
will probably be adjusting the second method (e-mail addresses inside
traditional DN's) to use CN="name <address>" rather than {CN="name",
RM="address"} since that seems more popular on the list and would cause
probably less heartache for existing PEM implementations.
2. While granting that you COULD break up the Internet name
into domainComponent names as you have suggested, I
don't understand any particular reason why you SHOULD
do so. It just seems to make a short Internet address look
like a complicated X.400 address, without adding any content.
I doubt that you intended to make it look more "official"? :-)
The primary reason is so that CA hierarchies based upon domain names
could be set up if desired, while obeying name subordination. More on
this later.
4. What else do we need? Well, in a previous message I
pointed out that even though any Internet mail address
is fully qualified, if you want to use it with any practical DUA
you'd better at least include the country code.
That is something that an X.500 expert should confirm I think. My
proposal was based squarely on one from an X.500 expert (Steve Kille)
which did not have the country code. But, putting the country code in is
no skin off my nose, as long as it is absolutely necessary.
You'll recall that my original proposal used C/O/OU with the top-level
domain mapped to a country code. There are two problems with this: (a)
some fiddling is needed for the US domains, and (b) some domains such as
"uk" actually map to country codes like "GB". What do we map "su" (Soviet
Union domain) to? Do we map it to the country code of the former republic
that the user resides in, or just "SU", or "RU"? These special cases
would have become ugly very quickly, especially (b) in today's changing
geopolitical environment. By sticking with the domain name we let the
Internet slowly evolve to incorporate the new codes over time, without
needing to add special case code to all PEM implementations each time a new
country splits off from an old one.
In my case, we would have
C=US, pemMailHost=GTE.COM, pemMailbox=Jueneman,
CN="Jueneman, Robert R."
pemDomain=com, pemDomain=gte, pemMailbox=Jueneman, CN="Jueneman, Robert R."
??
If my secretary had access to my mailbox to receive unencrypted
mail sent to me, but to sign mail only under her own name,
we would have
C=US, pemMailHost=GTE.COM, pemMaibox=Jueneman,
CN="Neilson, Theresa"
pemDomain=com, pemDomain=gte, pemMailbox=Jueneman, CN="Neilson, Theresa"
??
The major benefit of pemMailHost is that it is smaller in length. But,
the CA possibilities are lost without overhauling the name subordination
requirements at the same time. For example, GTE.COM may have (using your
encodings) the following as a CA DN:
C=US, pemMailHost=GTE.COM
Your DN and your secretary's are subordinate to this, which is good.
But, this DN is _not_ subordinate to:
C=US, pemMailHost=COM
Having such subordination may be important in a future version of DNS
that uses signing to assign authority for allocating portions of the
namespace to prevent DNS spoofing.
I've just had another look at RFC 1422, which clearly states that all DN's
on certificates must be subordinate to the DN of the issuer unless the
issuer happens to be a PCA or the IPRA. Hence, unless we were to make all
domains PCA's, this rule would be broken. In your case, it may make some
sense to have "C=US, pemMailHost=COM" be a PCA, but in my case, the
immediate parent of my domain would be "C=AU, pemMailHost=AU.EDU.QUT"
which would probably not make a good PCA.
This doesn't preclude us changing the subordination rules of course, but I
don't consider that part of my job of writing this draft: an overhaul of
certificate validation is better left to someone else more qualified than I.
I'm certainly willing to adjust my proposals to deal with new subordination
rules if necessary.
1) pemMailHost and pemMailbox ought to be of type
directoryString, and preferably Teletex, of length at least
64, and perhaps 128.
2) Internet mailbox names are not supposed to be case
sensitive, so the ASN.1 description should be:
pemMailHost ATTRIBUTE ::= {
WITH SYNTAX DirectoryString (ub-pemMailHost)
EQUALITY MATCHING RULE caseIgnorematch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
ID { id-at-pemMaiHost } }
No disagreement here. This is just technical stuff. The only question is:
once we decide upon what the attributes are going to be, who do I
contact (in the IETF or the IAN?) to be assigned a suitable OID?
Temporarily ignoring the potential requirement for supporting
both e-mail names and traditional DNs, would this scheme
satisfy your e-mail-as-DN objectives? If it does, I'll address
the other potential requirements next week.
Yours certainly satisfies my objectives, except for the CA one, and a few
quibbles about country codes. Except for that there is no functional
difference between our proposals: just different OID's used for certain
components.
Cheers,
Rhys.