On 12. 4. 2012, at 14:18, Dave Cridland wrote: > On Thu Apr 12 12:03:37 2012, Ondřej Surý wrote: >> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before discussing SRV records >> further. We have left SRV records on purpose and we expect that this will be solved in >> separate document (for each affected protocol). > Foolish me, I must have missed the reference to that ticket in the draft. > > Really, if this is out of scope, declare it as such - but then don't use SMTP either, given that's very close in spirit to SRV. > > But certainly for XMPP, DANE is currently insufficient, which is a real shame. We would certainly welcome new document defining interaction of XMPP and DANE. But I think that this needs to be crafted in the XMPP working group. >> > As a final comment, I'd presonally like to see some comments about how, and when, extended validation information should be checked and trusted. It seems to me that such information should be ignored when handling type 2 or type 3 certificates; or at best it should be validated independantly using the traditional methods - that is, it should be treated as a type 0 or type 1 certificate for the purposes of extended validation. >> I think that Extended Validation is out of the scope of this document. And if I am not >> mistaken the CA which are able to issue EV certificates are hardcoded in the browsers. >> Thus I think that DANE-aware applications can use standard rules for EV certificates. > > I think this needs calling out. EV seems like a very good argument for the existence of CAs in a DANE world; I think it would be beneficial to touch on the subject if possible. Alright point taken. I have opened http://trac.tools.ietf.org/wg/dane/trac/ticket/39 O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@xxxxxx http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------