Here's a practical example where this problem
might arise. Assume that two companies, A and B,
have cross-certified (maybe through a bridge CA,
maybe directly). The cross certificate from A to B
includes a name constraint of type rfc822Name
with permittedSubtrees of b.com. The CA for B
(or perhaps a rebellious or poorly managed
subsidiary CA) issues a certificate to an
individual with an EmailAddress attribute
with the value "prez(_at_)a(_dot_)com" in the subject DN
and a subject alt name of type rfc822Name
with the value "peon(_at_)b(_dot_)com".
Under the current text in RFC 3280 and under
Stefan's proposed revised text, a relying
party whose trust anchor is A will consider
this certificate perfectly valid. Unless their
email software is smart enough to know that
an EmailAddress attribute in the subject DN
is not checked for name constraints when
there's also a subject alt name and therefore
the EmailAddress attribute must be ignored,
the email software will be glad to verify
email claiming to be from prez(_at_)a(_dot_)com if the
signature can be verified with this certificate.
Why is this a problem? Because the name constraints
extension in the cross certificate was supposed
to prevent relying parties in A from accepting
certificates from B when an email address outside
of b.com as the subject DN or subject alt name.
I have cc'd this email to the smime WG. Maybe they
will tell me not to worry. Email clients are smart
enough to know that if a valid certificate contains
a subject alt name, then the EmailAddress attribute
in the subject DN cannot be trusted. But I don't
think email clients do this check. I certainly can't
find any language in RFC 2632 and its successor warning
people to do this.
Either RFC 3280 should consider the cert described
above as invalid or RFC 2632 should warn email developers
to ignore an EmailAddress attribute in the subject DN
if the certificate contains a subject alt name. Otherwise,
I think we have a security hole. Given the choice between
these two options, I'd rather change RFC 3280. Why?
First, I don't think that cert should be valid. Second,
it's usually easier to change the path validation code
and get that deployed (via an OS patch or equivalent)
than to change the email client code.
Thanks,
Steve
Stephen Kent wrote:
At 5:16 PM +0100 5/6/04, Stefan Santesson wrote:
I agree with Sharon here.
Even though it may sound logical to always also constrain e-mail
attributes, changing the standard in this aspect will just break many
current implementations and I don't think there is enough motivation for
it.
I too just see it necessary if no rfc822Name is present.
/Stefan
This is a slightly murky area. The e-mail address attribute is one that
we deprecate in 3280. It is a non-standard way of representing this
data; it was widely used in v1 certs, but ought to be scrapped for v3
certs. however, is it likely that a CA who goes to the trouble to
include the name constraints extension, and who explicitly includes an
rfc822name as an alt name, would also have the email address DN
attribute as well? I just wonder if this potential collision is at all
likely?
Steve
smime.p7s
Description: S/MIME Cryptographic Signature