Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-01.txt

Tim,

I think you might as well leave ‘activationTime’ as OPTIONAL element since it is sorta an operational strategy in this document intended to be a BCP. If so, the first MUST in the following text should be change to MAY.

The Signed TAL MUST have an "activationTime" that reflects when	
 	      Relying Parties MUST use use this new TAL in place of any	
 	      previously known TAL for this Trust Anchor.

Besides, it is lovely to see ‘deployment considerations’  included in this version and I am in favor of what is stated in it.

Di

P.S.

I found a nit in Section 6.1 that The sentence ‘The Trust Anchors MUST a new key pair and generate a new TA Certificate. ‘ just missed a verb ‘generate’.

> 在 2018年6月8日，21:37，Tim Bruijnzeels <tim@ripe.net> 写道：
> 
> Dear WG,
> 
> This a new version of the “Signed TAL” document that I presented on at IETF101.
> 
> The main changes in this version are:
> - Now supporting planned rolls only!
> - MAJOR change here:
> — No staging time!
> — BUT: Added steps for the TA to be sure that things work BEFORE publishing the new Signed TAL (I think this is better).
> - Included deployment considerations - essentially: once RPs support, roll often!
> - Do changes in URIs as planned rolls.. - included consideration section on this
> - No unplanned rolls, they are too complex and introduce a new key that can be compromised (now you have two problems) - included consideration section on this
> - Changed the structure of the object to have a version (definitely needed) and use ASN.1 structure rather than plain text or XML - inline with other RPKI Signed Objects
> - I included a “activationTime” element in the object to allow for future planned rolls, but I am not convinced that it’s really needed given the proposed procedure to set up the new key and test it first, and only then publish the Signed TAL - But, I don’t object strongly either.
> 
> As I said in London. I don’t think that we are close to the final word on this.. so I really would like to invite all of you to give this a good read and speak your mind.
> 
> I do want to keep the ball rolling. I think the experience with 5011 has shown that this should be addressed before there are too many implementations. So, I see urgency to address this.
> 
> Kind regards,
> 
> Tim
> 
> 
> 
>> On 8 Jun 2018, at 15:30, internet-drafts@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the SIDR Operations WG of the IETF.
>> 
>>       Title           : RPKI signed object for TAL
>>       Authors         : Tim Bruijnzeels
>>                         Carlos Martinez
>> 	Filename        : draft-ietf-sidrops-signed-tal-01.txt
>> 	Pages           : 12
>> 	Date            : 2018-06-08
>> 
>> Abstract:
>>  Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
>>  Relying Parties in the RPKI to locate and validate Trust Anchor
>>  certificates used in RPKI validation.  This document defines an RPKI
>>  signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be
>>  used by Trust Anchors to perform a planned migration to a new key,
>>  allowing Relying Parties to discover the new key up to one year after
>>  the migration occurred.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-sidrops-signed-tal-01
>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-01
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-01
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops