[dnsext] Moderate one's tone, please. (was: draft-jabley-dnsop-validator-bootstrap-00)

Not to pick on Paul, but again, I'd like to suggest a moderation of
tone.  I understand perfectly well that there are strong views here,
and I also think there is a perfectly legitimate technical dispute
here.  But let's go out of our collective way to keep our responses as
even as possible precisely so that we can get to a satisfying
conclusion for everyone.

Thanks,

A

On Mon, Jan 31, 2011 at 05:49:13PM -0800, Paul Hoffman wrote:
> On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote:
>> To be precise here, there is no difference in the likelihood that the
>> keys will be compromised.
>
> Quite right.
>
>> The difference is that the X.509 protocol is designed to support keys
>> that are persistent over long periods (decades) and DNSSEC is not.
>
> Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are  
> meant to last. Pretending that PKIX has some advantage here is nonsense.
>
>> In particular an X.509 self-signed certificate is an assertion that the
>> key holder will maintain and use the associated private key in
>> accordance with the specified practices for the specified length of time.
>
> Bosh. If you are talking about the "notAfter" field, it is defined as  
> the end of "the time interval during which the CA warrants that it will  
> maintain information about the status of the certificate"; that is quite  
> different than "maintain and use". If you are speaking of something  
> else, please quote from the PKIX spec.
>
>> You can easily find out how long Comodo or Symantec or whoever is going
>> to maintain their SSL CA roots, the information is right there in the
>> cert store and is irrevocable in that the CA can extend the time period
>> (through recertification) but cannot reduce it.
>
> Balderdash. When I look in Comodo's certificate in my "cert store", I  
> don't see anything about how long you are going to maintain your SSL CA  
> root. I see something that says you will maintain *information about the  
> status* of the certificate; note the difference. As for "irrevocable",  
> that's just silly: Comodo can revoke it at any time. There is no  
> contract here.
>
>> My advice to Cisco would be to use their existing root to sign the
>> published CSR for the DNS root KSK in the short term at least.
>
> Signing is the easy part: making their systems use that signed key is  
> much more difficult. That difficulty is what started this thread;  
> handwaving it away won't help Cisco or anyone.
>
>> In the longer term we are going to have to have a look at the problem at
>> a higher level and work out how we are going to solve it in a scalable
>> way across all the platforms that involve a root key.
>>
>> We are starting to make quite a little collection of industry forums
>> that are doing this root key management as a sideline.
>
> Now everyone can rest assured: industry forums to the rescue!
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.