ietf
[Top] [All Lists]

Re: https at ietf.org

2013-12-02 16:29:12
Phillip,

On Dec 2, 2013, at 1:02 PM, Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> 
wrote:
[...]


At no point did I suggest the key management processes were unique to ICANN nor 
did I suggest ICANN invented any of the processes out of thin air nor did I 
make any statement regarding the viability of online vs. offline signing of 
TLDs or the root or that the processes need be the same. You appear to be 
having a different conversation than the one Ted and I were engaging in and are 
attributing to me assertions I did not make (and don't necessarily agree with). 
I'm unclear how this is helpful.

My complaint was simply that I believe it is more useful to describe actual 
attacks and the vulnerabilities that allow for those attacks than it is to say 
"NSL" as if it a secret decoder ring.  Feel free to disagree with that 
complaint.

In that respect an NSL is unique to US jurisdiction, contrary to claims made 
by some. It is a warrantless search order. 

I would be surprised to discover the US is unique in allowing the existence of 
warrantless search orders under the guise of national security, however that 
does not appear to be relevant to this particular thread.

The point is that unlike the operation of (many? most? all?) commercial CAs, 
the operation of the root KSK by ICANN is public and open for 
input/improvement. As I said in a previous message "send text".
Every CA is required to publish a CP and CPS. These are public documents.

I was not talking about the documents, I was talking about the actual 
operations. As you've indicated in the Diginotar case "... the audit did not 
actually cover the public CA which it was used to gain inclusion in the root 
programs." Since as far as I know, _all_ handling of the root key by ICANN is 
done in a public way (see http://data.iana.org/ksk-ceremony/15/ for the 
recordings of the most recent key ceremony), I'm asking how would ICANN "turn 
Diginotar"?

Regards,
-drc

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

<Prev in Thread] Current Thread [Next in Thread>