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

[Terry Manderson <terry at terrym.net>]

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, Internet-Drafts at ietf.org wrote:

> 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.
> <mime-attachment>_______________________________________________
> sidr mailing list
> sidr at ietf.org
> https://www.ietf.org/mailman/listinfo/sidr