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

[Tim Bruijnzeels <[e-mail]>]

Hi Di,

I prefer to have “activationTime” either be mandatory, in which case it’s fairly trivial to set it to ‘now’ or ‘2 minutes ago’ even when one publishes, or not have it all and say that ‘activation’ is implicit because the Signed TAL is published.

This really depends on whether there is a good case for future dating.

Personally I don’t see this use case from the RP side. I would rather that I can just find whatever the TA thinks is the current TAL variables to use and switch to it immediately if they are different from mine.

From the TA side I think that if a TA does its testing and set up as described in section 6, before publishing the Signed TAL, then there is also no need for future dating.

The other issue I have with future dating is that I believe it makes things easy to reason about if there MAY be one, but only one, Signed TAL that describes the current TAL variables (URIs and Subject Public Key Info) to use. Having a future dated object, but no current, is confusing. Having two is more work and a bit confusing.

But if someone else does see a good case for future dating I would be happy to learn it.

Tim


> On 10 Jun 2018, at 09:52, Di Ma <[e-mail]> wrote:
> 
> 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 <[e-mail]> 写道：
>> 
>> 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, [e-mail] 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>>> 
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops