Subject: Re: SubjectAltName verification

From: [email-masked]
Date: Mon, 15 May 2000 15:48:55 -0400

Existence of an IP address, DNS name or E-Mail address is probably the
wrong check for a CA to perform anyway.  The worst problem related to this
would occur if I were to get a certificate with a subjectAltName containing
somebody else's valid E-Mail address, rather than if I got
"[email-masked]".

          Tom Gindin

Robert Moskowitz <[email-masked]> on 05/15/2000 02:09:10 PM

To:   "Martin Szotkowski" <[email-masked]>, <[email-masked]>
cc:
Subject:  Re: SubjectAltName verification

At 07:27 PM 5/9/2000 +0200, Martin Szotkowski wrote:
>Hi all,
>in RFC2459 (4.2.1.7) call :
> >>Because the subject alternative name is considered to be definitively
>bound to the publick key, all parts of the subject alternative name MUST
be
>verified by the CA.<<
>What exactly this means?

IMHO, this can only mean that the CA verifies that the content of
SubjectAltName follows the formatting rules of the CHOICE.  That is if
rfc822Name is used, then the rules of RFC 822 are followed.  If dNSName is
used, than RFC 1035.  etc.

These cannot be requied to be real values, that is some SMTP server respond
with an IDENT for the email and some DNS respond to a query.

WHY?

The mail or DNS server might be internal and unreachable to the CA.

IPsec looks at these as simple labeling formats.  This is particularly true
for dNSName for gateways on DSL models (ie 'mobile' gateways).

>Must be e.g. email unique in one CA? must be unique for one man?
>If yes, is there any way to determine that this man has this email? (How
>this problem is resolving for DNS, IP, URI, etc.?)
>If no, someone can stand out for some else in email communication?
>
>thanks for explanation
>Martin
>

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Paul Koning <[email-masked]>
Date: Mon, 15 May 2000 15:55:17 -0400 (EDT)

>>>>> "tgindin" == tgindin  <[email-masked]> writes:

 tgindin> Existence of an IP address, DNS name or E-Mail address is
 tgindin> probably the wrong check for a CA to perform anyway.  The
 tgindin> worst problem related to this would occur if I were to get a
 tgindin> certificate with a subjectAltName containing somebody else's
 tgindin> valid E-Mail address, rather than if I got
 tgindin> "[email-masked]".

Right.

How bad that is depends on what assumptions the relying party makes.
If he interprets the RFC text in the intuitively obvious way, that
could be quite nasty, because "definitively bound" and "verified" have
intuitive meanings that are rather strong.

If he read what Robert wrote and mentally substituted "the
subjectAltName doesn't have any particular meaning and nothing
significant is guaranteed about it" then of course there probably is
no problem.

But if that's what is meant, the RFC should be corrected to say so.
Right now, it sounds like the plain meaning of the words does not even
come close to reality, which is a Bad Thing.

    paul