However, I'd like to point out that this can be accomplished
today, _without_ any layering or changes to PEM:
Layering was a poor choice of word, I simply meant that we could
have several levels of functionality within a uniform design. The
alternative would seem to be having multiple "protocols" as
envisaged in the MIME-PEM I-D.
What your response shows is that many people are prepared to accept
the idea of having different levels of functionality in the system.
Probably even a rough consensus. [In fact people who don't want to
be in that rough consensus and won't be at Seattle should probably
say so now].
So perhaps all we are arguing about is technical details. Let me try
to convince you about one technical detail.
2. E-mail forgery protection.
...
or use an explicit
e-mail attribute (better), and have your DN be certified under a low
assurance PCA hierarchy that is based on e-mail names for identity.
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?
You need separate certificates for separate attributes and those
certificates should be signed by someone who is in a position to
vouch for that attribute.
Bob Smart