Subject: Re: [certid] [Spam] Re: URI match

From: "Erik Andersen" <[email-masked]>
Date: Thu, 1 Apr 2010 11:40:27 +0200

It seems that there is general requirement for URI matching. URIs are not
only used in subjectAltName, but are used in X.500 in general, i.e., for
RFID support. Defining uniformResourceIdentifier as just an IA5String may
also be a simplification.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af
Scott Cantor
Sendt: 1. april 2010 01:47
Til: [email-masked]
Emne: [Spam] Re: [certid] URI match

>> So, without defining further constraints an URI in subjAltnames is
>> rather useless, isn't it?
> 
> No, because we're trying to be inclusive regarding SANs at this point,
> and SIP certificates (as one example) prefer uniformResourceIdentifier.
> 
> However, I will work to clean this up some more in -04.

Somewhat paraphrasing a question that I think was asked at the app area open
meeting last week, is it the intention to encourage new protocols/services
that adopt/reference this proposal to favor matching based on URIs where
possible or appropriate?

That's something I'm in favor of, and I think worrying about what users
think they're connecting to is really beside the point; users don't get this
stuff. Our software is supposed to do the right things for them so that they
don't have to.

-- Scott

_______________________________________________
certid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/certid

---

From: "Scott Cantor" <[email-masked]>
Date: Thu, 1 Apr 2010 12:59:11 -0400

> also be a simplification.

However, matching on URI makes a lot more sense as a certificate constraint
if you also stop at that point rather than continuing to DNS or CN-based
matching. If you just keep going, it's not worth much.

I think it's very sensible to use URIs only but if that's not consistent
with the intent of the draft, it's probably a simplification to just advise
against it or leave it out.

-- Scott

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Apr 2010 13:15:44 -0400

On Wed, Mar 31, 2010 at 07:46:59PM -0400, Scott Cantor wrote:
> Somewhat paraphrasing a question that I think was asked at the app
> area open meeting last week, is it the intention to encourage new
> protocols/services that adopt/reference this proposal to favor
> matching based on URIs where possible or appropriate?

That would be my inclination: use an application specific SAN
form if possible. URI or SRVName would be the obvious candidates,
since they are general purpose. But some apps already define their
own custom SAN types. We do need to support current practice of
domain names in CN/dNSName though. The draft currently has this 
text:

   Futhermore, currently the vast majority of deployed application
   servers use domain names in their certificates (typically via a
   subjectAltName extension of dNSName or a subjectName component of
   Common Name).  Ideally, service operators would use application
   service identities in their certificates (such as an SRVName
   [SRVNAME], a URI, or an application-specific name form), since this
   would reduce the possibility of attacks against unrelated services at
   domain names that provide many different application services.

> That's something I'm in favor of, and I think worrying about what
> users think they're connecting to is really beside the point; users
> don't get this stuff. Our software is supposed to do the right
> things for them so that they don't have to.

Yup, absolute agree.

--Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Apr 2010 13:23:21 -0400

> matching. If you just keep going, it's not worth much.

Right. Most current software relies on being able to match any one
identity in the certificate. If there are multiple identities, then
the algorithm that should be used is to match more specific identities
first (eg. URI/SRVName before dNSName etc). I forget whether the
draft says that or not, but we discussed it.

Another way around this is to use URI/SRVName, but also have a 
dNSName that includes an "application specific server name" which
might need to be locally configured in the client. See:

  http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00935.html

In fact, for anyone not in the apps list, I'd recommend reading
the entire thread where some of these issues were discussed:

  http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00902.html

--Shumon.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Apr 2010 11:53:14 -0600

> draft says that or not, but we discussed it.

Yes, it's in the draft.

>   http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00935.html

Shumon, including SRV query names in dNSName seems novel to me. Is that
specified or recommended anywhere? Why not use SRVName instead and leave
dNSName as a pure domain name?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Shumon Huque <[email-masked]>
Date: Thu, 1 Apr 2010 14:01:47 -0400

> dNSName as a pure domain name?

Yup, that is novel, and needs more discussion, so I agree with you.

So the first example I proposed in that note is what I would deploy:

	dNSName mail.example.com
	otherName SRVName _imap.example.org

I wouldn't put "example.com" in dNSName, because then it didn't
constrain that certificate to only the IMAP service. Although I
fully expect some sites wouldn't care.

--Shumon.