Subject: Re: [sidr] Fwd: I-D Action:draft-ietf-sidr-ta-00.txt

From: Sandra Murphy <[email-masked]>
Date: Mon, 2 Mar 2009 06:17:21 -0500 (Eastern Standard Time)

You are right that there was no discussion about this.

I decided that the discussion about trust anchors demonstrated that we 
still had issues to work out in that area, and so moving that discussion 
to a different document made sense.  Since the working group had already 
accepted doing the work, the document devoted exclusively to that 
discussion was still an accepted working group work item.  And so should 
be a working group document.

--Sandy

On Fri, 27 Feb 2009, Danny McPherson wrote:

>
> Can someone please point me to the discussion that led
> to this being posted as a WG document, I can't seem to
> find it?
>
> Thanks!
>
> -danny
>
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: February 26, 2009 9:00:01 PM MST
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [sidr] I-D Action:draft-ietf-sidr-ta-00.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Secure Inter-Domain Routing Working Group 
>> of the IETF.
>> 
>>
>> 	Title           : A Profile for Trust Anchor Material for the 
>> Resource Certificate PKI
>> 	Author(s)       : G. Michaelson, et al.
>> 	Filename        : draft-ietf-sidr-ta-00.txt
>> 	Pages           : 17
>> 	Date            : 2009-02-26
>> 
>> This document defines a standard profile for the publication of Trust
>> Anchor material for the Resource Certificate Public Key
>> Infrastructure.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-00.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 3 Mar 2009 15:23:34 +1000

After a read through of the draft, I have some points to raise.

Section 1, Last paragraph

	"locally manage trust anchors in a fashion that preserves the  
resource subset constraints imposed by the use the RFC 3779 extensions."

	I think you mean

	"locally manage trust anchors in a fashion that preserves the  
resource subset constraints imposed by the use of RFC 3779 extensions.

Further from section 1. Is the structure really designed to enable RPs  
to self manage TAs?

Section 2: Para 1
	"This does not nominate any organizations as default trust anchors  
for the RPKI."

	Perhaps

	"This document does not nominate any organizations as default Relying  
Party (RP) trust anchors for the RPKI."

Section 2: Para 2
	"cannot be modified (undetectably) by other than the"

	i think you mean
	
	"cannot be modified (un-detectably) by anyone other than the"

Section 2 para 9
	Do you mean for the sentence "The format used to represent the ETA is  
based on ongoing IETF PKIX WG activities to define a format for trust  
anchor material." to be there? Or should it be in para 8? It just  
seems disjointed to me.

	And with that, do you have a draft reference to guide the implementer?

at the end of section 2 a diagram would be very helpful:

eg

ETA ---> CRL
     \----> EE ----> CMS [ payload: RTA (with 3779), signed attr ETA- 
EE ]

Section 3, para 1
	"This suggests that the structure of certificates in the RPKI that  
relate to the use of public number resources is a public context"

	maybe

	"This suggests that the structure of certificates in the RPKI that  
relate to the use of public number resources in a public context"

Section 3 para 2

	Would the authors consider saying that RTAs from two putative public  
TA organisations must not overlap?
	Just so we really do try to avoid the state of two organisations  
claiming to be authoritative for the
	same information?

Section 3 para 5+

I have some questions about the recommended operational maintenance  
procedure.

Early in the document it is suggested that the ETA be an offline CA  
yeah? Its fine to publish a CRL for the offline ca, however section 3  
suggests that the ETA issue a CRL shorter than the validity period for  
the RTA. This pseudo synchronisation implies the ETA will need to  
regularly brought back online for CRL issuance which tends to negate  
the concept of a long lived crl from an off-line CA. Or have I  
incorrectly interpreted what you are saying? I think the same goes for  
where a trust anchor re-issues the RTA. The frequency of this implies  
that both the RTA and ETA will be on-line CAs.

or perhaps you can help me understand why a new ETA-EE certificate  
needs to be created to sign the CMS for the new RTA? I see that you  
are tying to signify to relying parties that the RTA has changed and  
they need to fetch the RTA CMS blog, but wouldn't a manifest be of  
more utility and provide for less cert churn?

I agree also with the authors note, a diagram of the SIA, locations,  
and crl locations would be helpful.

Further, can you separate the 'private number' items into their own  
headings in the documents?

Cheers
Terry

On 27/02/2009, at 2:00 PM, [email-masked] wrote:

> This draft is a work item of the Secure Inter-Domain Routing Working  
> Group of the IETF.
>
>
> <mime-attachment>_______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Terry Manderson <[email-masked]>
Date: Wed, 25 Mar 2009 06:25:29 +1000

Post Geoff's presentation today I thought I would quickly email  
regarding one point he mentioned, and no one contested.

The authors of the draft believe that there should not be an IANA  
considerations section as there are no protocol number requirements.  
While the general interpretation of RFC2434 relates to protocol  
numbers, I think it is important to note that the descriptor to use is  
'a namespace' and, in that RFC, is far more broad. I feel as rpki  
relates so tightly to a set of known registries that an IANA  
considerations section can be used with without major issues. (and  
demonstrated in RFC3152 which directs the IANA to a course of action)

While I tend to agree with Dave's on mic comments that there needs to  
be a binary decision and then a pros/cons section in a (the) draft to  
discuss _technical_ observations between single and multiple TAs, I  
feel it does not detract from the authors stance of sitting on the  
fence to promote the existing "recommendation" regarding IANA being a  
default TA for public address space to the IANA Considerations section  
and maintained post RFC publication.

I would like to say, in the post glow of the WG meeting, that I really  
appreciate and commend Geoff for identifying his previous  
organisational attitude towards previous authored drafts and his  
efforts to present a view that is distanced from his employer. Thankyou.

and slightly askew..
Do I think that process was side-stepped in this draft going straight  
to WG status and not via an individual submission? Maybe, but I do  
observe that while there was objection regarding the Co-chairs  
decision I suspect it would be process alone that would require a  
token individual submission before becoming a WG item. So its not  
going to burn me if it stays as a WG item. Equally if it serves the  
proper and just process to make it a indv. submission I can go there  
too as a WG participant.

Cheers
Terry

---

From: Danny McPherson <[email-masked]>
Date: Tue, 24 Mar 2009 19:25:51 -0600

On Mar 24, 2009, at 2:25 PM, Terry Manderson wrote:

> Do I think that process was side-stepped in this draft going  
> straight to WG status and not via an individual submission? Maybe,  
> but I do observe that while there was objection regarding the Co- 
> chairs decision I suspect it would be process alone that would  
> require a token individual submission before becoming a WG item. So  
> its not going to burn me if it stays as a WG item. Equally if it  
> serves the proper and just process to make it a indv. submission I  
> can go there too as a WG participant.

My point was that process was not followed - it had nothing
to do with the content of the draft.

Given the contentiousness of this topic and the importance
and architectural implications therein, I maintain my position
that process needs to be followed here.  Something that you or
the chairs believe is trivial may well be of considerable
concern to others more or less informed.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 24 Mar 2009 19:32:26 -0600

> concern to others more or less informed.

And in fairness and for sake of transparency, to illustrate
my point:

<http://www.iab.org/documents/correspondence/2008-12-04-huston-TAs-IANA-RIRs.html 

-danny