Re: [dispatch] DANE SRV draft and SIP

["Olle E. Johansson" <[e-mail]>]

22 apr 2013 kl. 20:28 skrev Peter Saint-Andre <[e-mail]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 4/22/13 12:18 PM, Olle E. Johansson wrote:
>> 
>> 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)"
>> <[e-mail]>:
>> 
>>> While there was never a formal mailing list poll (because we
>>> never got to the point of needing a 3261bis), I think there was a
>>> considerable body of opinion during the development of
>>> domain-certs that the material would form part of any 3261bis
>>> work. That I think lends support to any further work being done
>>> in sipcore.
>>> 
>>> I do suggest you look back in the archives for the mailing list
>>> discussion on domain-certs. You'll find it on the sip (not
>>> sipcore) mailing list archive. You'll find the WG discussion
>>> between Feb 2008 and April 2009 with the IESG approval discussion
>>> continuing until May 2010.
>> 
>> Keith, Thank you for the reference.
>> 
>> Note that I'm not saying that  RFC 5922 is wrong. The issue at hand
>> is that the DANE groups current RFC suggests a solution not
>> compatible with 5922. We need to decide which way to go.
>> 
>> We could recommend that the DANE way is used when DNSsec and DANE
>> validation is possible, and keep RFC 5922 for other cases.
> 
> Well, it's clear to me that we wouldn't allow checking of the derived
> domain (in RFC 6125 terms) unless DNSSEC validation succeeds. Since
> that is currently a rare event, we'd just continue to do what RFC 5922
> says, which in draft-ietf-xmpp-dna we call the PKI prooftype.
I'm not sure that the certificates would be compatible, which is a problem.
A non-DNSsec client following RFC 5922 requires one certificate with domain
names and the DNSsec/DANE client would require host names in the
same certificate - unless we have certificate selection (TNI).

Being tricky one could possibly have the host name in the CN
and add SIP domain URIs in subj alt names.

> 
>> Or update the recommendation in 5922 to make sip with TLS better in
>> regards to hosting larger amounts of domains.
> 
> I think that is somewhat a separate issue from defining the DANE
> prooftype, because other prooftypes might be possible or more
> deployable in the short term, such as the POSH prooftype that Matt
> Miller and I have defined in draft-miller-xmpp-posh-prooftype (but
> which is not specific to XMPP).
I need to read up on your drafts, but how do you handle certificates
for one server supporting multiple prooftypes? Are they compatible
in XMPP?

/O
> 
> Peter
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRdYFEAAoJEOoGpJErxa2pLCoP/1wYQA2CGqmaCwtG0udAP9bL
> PyaYjqWqofvEdnJk/Nm/HKZdZ3MuGzpqydWo11Yi/GOyyjIzZrNQKZ2c4gPhCiNB
> KdOMiMGBU625vsCJjhu8E5b14sXc4lJc7iEf2dfmMQpwer26YmGrRpolVSsBZ/td
> 3FvkbPChbC9zg8YHSN9k9tkQlxfwwK5sjgIMDGtOhaKnhUBlIiGV0iTXZL1nkMdq
> X9DUWzlvCHxNHWB2W1nbtYagNWu6QaoJTI88O/5qcwP4pZsrHbhelvqeuERfF+sY
> sBIBrxYBNUhM9a7wWhxrlqSBeM/nt/oM46osV/sI5qrobkNs26l7hHkh/CVzpr/H
> 72c1PaujqKJx4Osidyi24a9Lc6JTke/v4gr+ObN9zDBaUvAcXghqk73j8P2rUsj+
> T64/lN1n22G87d9sdi9X7RUdfTlPmg65CFmfhBMTfYnz2ZL7YzVxvnKs+Q/BF/1S
> 7pHMJoviKM7V1cx3OYaEBqFnnRzWOlcfrULzy0VrFw7IjxD6+W9RxGoi2Zv1R2xL
> tBy+FV9iUXS9CHyrEmjm+DYgqopg70PCaIEjHZzrC2SCbWw2DBbP0K/d5YL51Vmz
> Hyz8T3h4pSfgkwa/wPs7WeP6UrHV3Cz66077L+taLuT1NV7JP1lr9L8pLDMj6xQ8
> fpkwx+0yZnAY8VBDp76A
> =6W3o
> -----END PGP SIGNATURE-----