Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Steve Schultze
On 2/11/11 6:04 PM, Eddy Nigg wrote: Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.COM, BANK0FAMERICA.COMall goes. Of course not, that's why we have this: http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf Have you actually read that report? It details a rapid resp

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Eddy Nigg
Last reply, I promise... On 02/12/2011 12:50 AM, From Stephen Schultze: Today's DV CAs already rely on a self-assertion of domain control, and they in turn assert that they observed this. In plain english, a DV cert says, "The guy holding the corresponding private key asserted that he control

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Eddy Nigg
On 02/12/2011 12:32 AM, From Stephen Schultze: Who the subscriber is (not higher level validation, sanity check) I still can't decipher this. I didn't expected that you do :-) what the requested host name is There is no ambiguity in DANE. Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.C

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Stephen Schultze
On 2/11/11 3:11 PM, Eddy Nigg wrote: improves reduces the spectrum of exploits... does this make any sense? Thanks typo cop. I'm sure it's clear what I meant. . It also places revocation power directly in the hands of the subscriber. That's the same as self-assertion. Most subscribers

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Stephen Schultze
On 2/11/11 5:57 AM, Eddy Nigg wrote: 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) I still can't decipher this. what the requested host name is There is no ambiguity in DANE. what's the purpose of

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Eddy Nigg
On 02/11/2011 05:56 PM, From Stephen Schultze: Thus, the CA DV model provides no clear comparative benefit with respect to revocation abilities. In fact, by removing the need to proactively revoke, DANE improves reduces the spectrum of exploits improves reduces the spectrum of exploits...

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Stephen Schultze
On 2/11/11 4:39 AM, Rob Stradling wrote: On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote: - OCSP and CRLs are unnecessary with DANE Steve, may we presume that you only intended this statement to apply to the use of self-signed certs with DANE? When an EV (or OV) certificate issued by a t

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Eddy Nigg
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 DAN

Re: TLS server keys in DNS: client policy proposal

2011-02-11 Thread Rob Stradling
On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote: > - OCSP and CRLs are unnecessary with DANE Steve, may we presume that you only intended this statement to apply to the use of self-signed certs with DANE? When an EV (or OV) certificate issued by a third-party CA is used with DANE, I would