Subject: RE: authority for a domain (was RE:[Sip]sip-identity-05:display-name woes)

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 22 Apr 2005 19:50:32 -0400

My goal here is to require nothing other than what is commonly used by certificate authorities today for web server certs. Go look at the certificate you get from a TLS connection to Amazon, eBay, Paypal, take your pick. The domain is in the CN field.

If we specify only SAN, and people cannot get certificates from existing common CAs that put the domain in the SAN, we have a problem.

Anyway, the text in sip-identity-05 does not restrict the presence of a domain name to the CN - it also talks about checking the SAN.

Jon Peterson
NeuStar, Inc. 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Friday, April 22, 2005 4:01 PM
> To: Peterson, Jon; Michael Thomas
> Cc: [email-masked]; Francois Audet; Paul H Kyzivat
> Subject: Re: authority for a domain (was
> RE:[Sip]sip-identity-05:display-name woes)
> 
> 
> On 4/22/05 3:26 PM, "Peterson, Jon" <[email-masked]> wrote:
> 
> > I've tried to clean up this language a bit for -05, and 
> hopefully it will be
> > an improvement. In the first place, I now talk about 
> domains appearing in the
> > CN field of the subject of the cert as well as the 
> subjectAltName. Our aim
> > here is to correspond exactly with the conventions for 
> identifying web servers
> > in the existing e-commerce field, so, using the CN field of 
> the subject is
> > actually more accurate (though I understand subjectAltName 
> is used as well
> > when multiple hosts are subjects of the same certificate, 
> as is the case in
> > some web hosting architectures).
> 
> Not sure I agree here. SN was horribly underspecified and 
> caused all sort of
> complicated problems. SubjectAlntName (SAN) corrects these 
> and we don't have
> a backwards compatibility problem here. 3261 is very clear 
> that the certs
> used for SIP have to have a SAN - this allows SIP to avoid a 
> ton of problems
> is is not really a big deal for implementers or CA. I think we should
> continue using the same sort of certificates for SIP identity 
> that we use
> for 3261. 
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Apr 2005 08:47:27 -0700

I've been working with some of the major CA vendors to make sure they can
tell people have to get certificates that have the name in the
SubjectAltName. Actually many of them already do it but you have to have to
ask for a "Microsoft Small Business Server certificate" - they use Subject
Alt Name. Some other ones, when you send them a Certificate Signing Request
with a Subject Alt Name they do it fine, some other strip it.

I can not imagine why we would go to the effort of making Identity work with
certificates that would not work for RFC 3261 TLS. If we want to go back and
upgrade 3261 and Identity so they both have all the text so that people can
successfully parse the Common Name stuff we could but I think we should both
or neither. I some favor the path of getting it so that CA and people know
how to provide certs with the Subject Alt Name set correctly is a better
path but I can go either way.

Cullen

On 4/22/05 4:50 PM, "Peterson, Jon" <[email-masked]> wrote:

> 
> My goal here is to require nothing other than what is commonly used by
> certificate authorities today for web server certs. Go look at the certificate
> you get from a TLS connection to Amazon, eBay, Paypal, take your pick. The
> domain is in the CN field.
> 
> If we specify only SAN, and people cannot get certificates from existing
> common CAs that put the domain in the SAN, we have a problem.
> 
> Anyway, the text in sip-identity-05 does not restrict the presence of a domain
> name to the CN - it also talks about checking the SAN.
> 
> Jon Peterson
> NeuStar, Inc. 
>