At 11:48 AM -0700 3/26/08, Eric Rescorla wrote: >At Wed, 26 Mar 2008 10:16:08 -0700, >Paul Hoffman wrote: > > >> Greetings. Robert Sparks mentioned to me that this document is in WG >> Last Call. I am familiar with PKIX and make these comments based on >...snip... > > subjectAltName. Because of this, I suggest taking out this option >> everywhere in the document; you'll get much better interoperability >> if you do. > >So, I have no brief for one design or the other, but I think >we can agree that it's imperative that this work with certs >from commodity CAs. Has someone published a survey of which >CAs will give you SAN?
From what I have heard, all of them will, and all of them that don't ask "CN or SAN" give them in SAN. I could be wrong, of course. I'll ask on the PKIX list, and will report back. >SIP is not HTTP, and does not support Basic authentication. Got it. Sorry for missing that one. At 2:40 PM -0500 3/26/08, Vijay K. Gurbani wrote: >Right; so when we first started this work, there was a tacit need >to support existing certificates -- not designed for the use of >SIP, per se -- that would not have the domain name in SAN, and >instead would have it in the CN (existing web certificates re-used >for SIP, for instance.) These certificates would need to be >supported as well. Hence the imperative to implementors to check >the CN if SAN is empty; the imperative to service providers to >use SAN; and in sip-eku, the imperative to a CA to insert the >identity in the SAN. Given that there is now lots of interop experience with SIP-over-TLS, has anyone checked the certs floating around for whether there are any using domain names in CN? If not, you shouldn't have to drag around that baggage. >>- The logic in item 1 of section 7.1 is confusing. If there is no >>sip: URI, but there is a DNS name, why is accepting it a MAY? >>Shouldn't this be a MUST for interoperability? If it is only a MAY, >>where else would the relying party get a useful SIP host identity? > >Our thinking was that whether to accept a DNS type in the SAN >is up to the individual policies of the service provider. Ought >this be made more explicit? Or other avenues explored? With the current wording, two systems will only be assured of having interoperability if they both have sip: URL in the certs. That goes directly against what you say above about the "tacit need" to support existing certificates. The "MAY" gives you an increased chance of interop, but far from a guarantee. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
