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 > my knowledge of PKIX, not based on my small knowledge of SIP.
Paul: Thanks for your time on reading the drafts (my co-author and I owe you a response on the sip-eku as well.) But for this one, please see inline. > In general, this document seems fine. However, there are some points > worth noting. > > - Steve Kent's comment about domain names in the CN is right: there > is no reason for this group to standardize on allowing domain names > in CNs. We have found almost no CA software that in practice today > will only put a domain name in the CN; those that even allow doing so > (which thankfully is few) have an option for putting it in the > subjectAltName. Because of this, I suggest taking out this option > everywhere in the document; you'll get much better interoperability > if you do. 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. > - 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? > - The document incorrectly talks about Digest authentication as the > only way that a SIP server running TLS can authenticate a client. > Basic authentication is just as good in such a case, and has many > properties that make it better than Digest when used under TLS. The > document should only talk about HTTP authentication, not Digest or > Basic. RFC3261 deprecated Basic authentication. Only Digest is supported in rfc3261. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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
