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(_dot_)sury(_at_)nic(_dot_)cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------