Subject: [Sip] [Fwd: Re: Status of domain-certs-01 and sip-eku-02]

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Jul 2008 11:34:08 -0500

FYI -- some discussion on PKIX list about the sip-eku issue I
pointed out in my email yesterday.  It may be the case that
the use of EKU as we have it in sip-eku-02 is okay after all.

Scott and I will let the SIP WG know of the final outcome.
We will summarize discussion from PKIX list to the SIP WG list
as needed.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

Subject: Re: Status of domain-certs-01 and sip-eku-02
From: Stephen Kent <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
Date: Tue, 15 Jul 2008 12:06:47 -0400

Paul,

>>...
>
>A brief history here. The document is specifying "the semantics of 
>the domain name that is the subject of this certificate is Foo, not 
>Bar which is what you might have expected". They used an EKU because 
>other people had used EKUs for things they thought were similar.
>
>I pointed out that a KU describes a usage of the key, not a semantic 
>for the subject. From a PKIX semantics standpoint, they way to talk 
>about the semantics of the subject is with an extension.

I think it is more appropriate to focus on the EKU text from 5280, 
vs. the KU text, since the proposal is to assign an EKU OID for this 
use of certs. Section 4.2.1.12 describes the EKU extension and gives 
examples. The examples include TLS server vs. client authentication, 
code signing, time stamping, and OCSP response signing.  These 
examples from 5280 illustrate using EKU to signal what type of entity 
holds the corresponding private key, and for what purpose that key is 
being used.

So, using an EKU to signal that the private key holder is a SIP proxy 
(e.g., vs. a SIP end entity) is clearly consistent with the examples 
cited in 5280. I think that using an EKU to signal that the DNS SAN 
in the cert is to be used to constrain the range of SIP IDs can be 
verified using the cert is not completely inappropriate either.

Steve
_______________________________________________
Sip mailing list  https://www.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