Subject: [sidr] slight whoops ...

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Mar 2013 16:52:57 -0500

Sean,

I forgot to reply to your first comment. See what happens when you label 
it "0"?

0) Based on the assumption that draft-newton-sidr-policy-qualifiers will 
be adopted because that's what the RIRs want should s1.2 or 1.5 also 
include some information about where it can be found?  This information 
would be identical to the URI included in the policy qualifier?

I suggest the following added text for 1.2:

<If this document is available via the Internet, the CA can insert the 
URI for the CPS here. It should be the same URI that appears as a policy 
qualifier in the CA certificate for the CA, if the CA elects to make use 
of that feature.>

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Mar 2013 06:56:31 +0900

> be adopted

i simply do not understand the utility of that draft

either no one ever sees the urls, or they are a malware attack vector.

randy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Mar 2013 17:44:46 -0500

Typically the rationale for the URI is so that the a CA can satisfy it's 
legal counsel that
potential relying parties have been informed, via the URI, of the 
presence of a CPS, and
that RPs who care can download and read it before maknig use of the 
certs issued by the CA.

Its a CYA mechanism.

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Mar 2013 07:47:03 +0900

> Typically the rationale for the URI is so that the a CA can satisfy
> it's legal counsel that potential relying parties have been informed,
> via the URI, of the presence of a CPS, and that RPs who care can
> download and read it before maknig use of the certs issued by the CA.
> 
> Its a CYA mechanism.

it is an arin disease that opens the user to malware attack.  just say
no.

randy

---

From: John Curran <[email-masked]>
Date: Wed, 6 Mar 2013 00:23:55 +0000

> it is an arin disease that opens the user to malware attack.  just say

Randy - Feel free to omit the URI to the CPS in certs that you issue, but 
that should not preclude others from including them so if they so desire.

Thanks!
/John

John Curran
President and CEO
ARIN

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Mar 2013 10:05:51 +1000

On 06/03/2013, at 8:44 AM, Stephen Kent <[email-masked]> wrote:

> Typically the rationale for the URI is so that the a CA can satisfy it's legal counsel that
> potential relying parties have been informed, via the URI, of the presence of a CPS, and
> that RPs who care can download and read it before maknig use of the certs issued by the CA.
> 
> Its a CYA mechanism.
> 
> Steve

I support this draft as APNIC has a similar requirement to satisfy our legal counsel in the manner described by Steve.

thanks,

-George

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Mar 2013 08:20:25 -0500

That works for me.

spt

---

From: [email-masked]
Date: Thu, 07 Mar 2013 12:54:52 -0700

I understand why ARIN wants this -- I'm sure our legal folks would want 
something similar if we were in their predicament (i.e., one more place 
for indemnification against failures, compromises, actions of 
[grand]parents, etc..), reading the current RPA makes this clear:

S.7 ...."You shall indemnify, defend, and hold harmless ARIN and CAs 
and each of its respective parent and subsidiaries, each of their 
respective predecessors, successors and assigns, each of their 
respective employees, representatives, agents, attorneys, advisors, 
trustees, directors, officers, managers, and members from any and all 
claims, demands, disputes, actions, suits, proceedings, judgments, 
damages, injuries, losses, expenses, costs and fees(including reasonable 
attorneys’ fees and expenses), interests, fines and penalties of 
whatever nature (collectively, “Claims”)"......

With the likes of grandparenting and the potential implications RPKI 
could have on operational systems and real networks, this seems quite 
prudent to me.  Furthermore, I'm not sure how anyone that operates 
infrastructure could be expected to take on liability where their 
"parent" or others in the system could impact the service they provide, 
and they could be liable.  The joys of production...

> it is an arin disease that opens the user to malware attack.  just 

I'm not sure I understand how this "opens the user to malware attack", 
could you please explain?  I understand the DoS vector, this certainly 
exists for all of RPKI, but I don't understand "malware attack" and 
think if you have any additional text related to that it ought to be 
reflected alongside the current DoS text in the Security Considerations.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Mar 2013 15:18:10 -0500

On Thu, Mar 7, 2013 at 2:54 PM,  <[email-masked]> wrote:
> I'm not sure I understand how this "opens the user to malware attack", could
> you please explain?  I understand the DoS vector, this certainly exists for
> all of RPKI, but I don't understand "malware attack"

please click on this link to accept my TOS:
  <https://badplace.com/malwareCPS.cps.doc.exe.pdf.gif>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 07 Mar 2013 13:25:39 -0700

>   <https://badplace.com/malwareCPS.cps.doc.exe.pdf.gif>

That could be included anywhere - and if it's in a resource certificate 
then you've got far bigger problems than a "malware attack", methinks.

Heck, this might well serve as an early indicator of compromise, if we 
really believe this is a legitimate issue.

It also applies to ANY publication mechanism in any protocol, so I 
think it's rather a bit of a reach.  Of course, I look forward to text 
from "malware attacks" in all IETF documents going forward, and this one 
specifically..  :-)

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Mar 2013 15:26:43 -0500

On Thu, Mar 7, 2013 at 3:25 PM, Danny McPherson <[email-masked]> wrote:
> That could be included anywhere - and if it's in a resource certificate then
> you've got far bigger problems than a "malware attack", methinks.

agreed, there's also dns pinning and a host of other ways.

> It also applies to ANY publication mechanism in any protocol, so I think
> it's rather a bit of a reach.  Of course, I look forward to text from
> "malware attacks" in all IETF documents going forward, and this one
> specifically..  :-)

yea, it'll be fun! :)

-chris

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 7 Mar 2013 15:46:18 -0500

>  <https://badplace.com/malwareCPS.cps.doc.exe.pdf.gif>

Wait, does that mean that the sidr mailing list is a malware vector too?  Maybe we should shut the list down too?  ;)

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Mar 2013 16:58:00 -0500

> Wait, does that mean that the sidr mailing list is a malware vector too?  Maybe we should shut the list down too?  ;)

yes, please download this update to your codec, it'll make viewing the
mailing list easier:
  <http://codecupgrades.com/i/will/not/spit/in/your/ear.exe>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 Mar 2013 17:26:00 -0500

>  <http://codecupgrades.com/i/will/not/spit/in/your/ear.exe>

That URL didn't work for me, but I think it is my machine, not your Internet, because a Nigerian prince sent me the same link and it didn't work then either….

W

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
> 

--
I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, with great presence of mind, they brought Thousand Island Dressing and a bottle of chili sauce.
    -- Terry Pratchett