Subject: RE: SubjectAltName verification

From: Al Arsenault <[email-masked]>
Date: Mon, 15 May 2000 14:50:33 -0400

I have to disagree with Bob on this. To me, the words imply what they say - 
that if the CA is going to issue a certificate that says that my 
subjectAltName of the form rfc822Name is "[email-masked]", the CA 
must have taken some steps to verify that that is indeed the case.  (e.g., 
the CA could have a notarized letter from the authority responsible for 
assigning those e-mail addresses.)  To do otherwise is false or misleading 
behavior on the part of the CA.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

-----Original Message-----
From:	Paul Koning [SMTP:[email-masked]]
Sent:	Monday, May 15, 2000 2:22 PM
To:	[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	Re: SubjectAltName verification

>>>>> "Robert" == Robert Moskowitz <[email-masked]> writes:

 Robert> 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?

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

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

 Robert> WHY?

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

It may well be that it's hard or impossible to do more.

But this is NOT what the words quoted would suggest, not at all.
"Definitively bound to" and "verified" does not intuitively translate
to a mere syntax check.

   paul

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 15 May 2000 15:05:25 -0400

>behavior on the part of the CA.

First question:

What are we going to use as the SubjectAltName in your Netopia box on your 
DSL line in your house, Al?  Shouldn't be YOUR email address, Al.  What 
FQDN?  Remember there is no static IP address for you, everytime you boot 
the Netopia, it can get a new IP address from the ISP.

Taking the FQDN further, these are internal boxes, getting a third party 
cert.  The CA cannot do a DNS query on the internal DNS server.

This all comes down to the CP and CPS.  Here is where is stated the method 
use to establish the content of SubjectAltName.  Now it would be really 
nice if there were a KEYNOTE object in the cert that would express the 
method of validation...

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 15 May 2000 12:24:01 -0700

At 3:05 PM -0400 5/15/00, Robert Moskowitz wrote:
>>I have to disagree with Bob on this.

Me too. "definitively bound" seems to be very, well, definitive.

>What are we going to use as the SubjectAltName in your Netopia box 
>on your DSL line in your house, Al?

I'm not Al, but I will answer: anything the CA wants. There are a 
variety of identifiers that a CA can use for the end entity. The CA 
should obviously use an identifier that the desired relying parties 
want to use.

>   Shouldn't be YOUR email address, Al.  What FQDN?  Remember there 
>is no static IP address for you, everytime you boot the Netopia, it 
>can get a new IP address from the ISP.

That doesn't mean that there is no FQDN that will map to your router. 
Your ISP might (should?) be using DHCP with dynamic DNS that updates 
the FQDN each time the IP address changes. These have been around for 
years and have been shown to be interoperable.

>Taking the FQDN further, these are internal boxes, getting a third 
>party cert.  The CA cannot do a DNS query on the internal DNS server.

Then the CA should not issue a cert using those types of identifiers. 
There are lots of other choices for types of identifiers, some of 
which might be appropriate for relying parties. If not, well, then 
there's no way for someone to identify the box in a cert.

>This all comes down to the CP and CPS.  Here is where is stated the 
>method use to establish the content of SubjectAltName.

If the CPS says "I didn't check the binding between the ID and the 
public key" or "I checked it at the time of issuing but you probably 
won't be able to check it now", I would argue that no one should rely 
on that certificate.

>   Now it would be really nice if there were a KEYNOTE object in the 
>cert that would express the method of validation...

That won't help if there is no way to come up with a useful identity 
for the relying party.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 May 2000 00:45:40 -0400

Bob,

The underlying assumption is that the CA is vouching for the accuracy 
of ALL data in a certificate.  A syntax check is NOT what one would 
expect. yes, the CPS may hedge on how good a check the CA does, but 
there IS a presumption that the CA has made some effort to verify the 
info.  We long ago debated this issue; some folks wanted to have a 
flag for a CA to set to indicate the presence of non-verified data. 
We rejected that approach.

Steve