On 02/11/2011 07:08 AM, From Steve Schultze:
Can you give an example?
Who the subscriber is (not higher level validation, sanity check), what
the requested host name is, what's the purpose of a certificate,
cryptographic weaknesses, to name a few.
Would these checks be necessary under DANE or are they specific to
the CA third-party-domain-validator model?
I believe that they are necessary and requires involvement of a third
party (if you want, you can call it something else than CA ;-) )
With DANE, such checks are part of the spec and the client
implementation. As we have seen repeatedly on m.d.s.p., relying on
CAs to enforce checks consistently is far less effective than
implementing hard client checks.
Well, as a matter of fact, the specs exists today for CAs too and are
not enforced on the client side. What makes you believe that anything
will change in this respect? By all means, how should individual users
be more compliant to specs than CAs?
Unnecessary with DANE.
A review of the requested properties in a certificate are an obvious
benefit, it's not unnecessary with keys-in DNS, it's not possible.
I've made clear that I'm not a fan of such nannyism.
So? Maybe you are not (that's your own problem which is not shared by
the software vendors amongst other things), but it's a one of the tools
CAs have and use when necessary.
To the extent that it has to be done, the registries/registrars are
simply a more direct path.
You make me laugh - registrars couldn't care less as the facts show!
Otherwise why should CAs and software vendors have to use phishing and
other detections, why huge blacklists of hostnames exists for domains
that are never pulled, being used for anything from spam, phishing,
malware distribution and more.
This has been going on for more than a decade and nothing has been done
by the registrars. And you want to convince the audience that they will
suddenly turn inside-out and be even more responsive and responsible
than CAs? LOL
In many cases they already have revocation-for-bad-behavior policies
in place.
If your registrars would have done a better job and perform some due
diligence, this wouldn't be necessary in first place. And interestingly
you are defending such policies by registrars and deny the same for CAs
as useless. :-)
With DANE, "revocation" of keys by the owner of the domain
You are joking, aren't you? :-)
(I will phish, spam, distribute malware and viruses, scam, all the while
using secure TLS channels and even revoke my own keys because I have
been a naughty boy doing all those things :-) )
Additionally, DV may protect against a shortcoming of DNS that is
happening now and possible wrongful issuance of a DV certificate may be
detected due to shortcoming of DNS. Those are just the very obvious
points I mentioned before. Keys-in-DNSSEC can't provide that without the
involvement of a third party like a CA.
I can't figure out what this means.
A flaw in DNS (we will probably see them with and without DNSSEC), a
compromise thereof can be prevented even with DV certs, not with
Keys-in-DNSSEC. It will be Kaminsky all over again.
- OCSP and CRLs are unnecessary with DANE
It's not unnecessary, it's not possible. There is no meaningful
oversight and no option to intervene besides the ever so responsible
registrars. That's why CA certificates are so great :-)
- Can you point me to the place in the Moz Cert Policy that requires a
contact for "misuse" or defines what that term would mean?
I believe it was discussed and incorporated into the policy, will look
for it.
- Audits and the like serve only to limit the *additional* risks that
the CA DV model poses *on top of* its blind reliance on DNS.
Which clearly shows your lack of knowledge. As I said earlier, I've been
on both sides of the fence and I believe you simply are missing a couple
of important things here. The above statement illustrates it best.
So all of these items you mentioned really only pertain to domain
validation, and involve implicitly trusting DNS, as I originally stated.
Well, you can call white black and vice versa and we'll probably will
not convince each other. Also not necessary.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: start...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
