[Sidrops] Re: Paul Wouters' No Objection on draft-ietf-sidrops-signed-tal-15: (with COMMENT)

[Paul Wouters <[e-mail]>]

thanks for the clarifications!

paul

Sent from my iPhone

> On May 15, 2024, at 21:13, Tom Harrison <[e-mail]> wrote:
> 
> Hi Paul (and Job),
> 
> Thanks for your review.
> 
>> On Wed, May 15, 2024 at 08:26:21PM +0200, Job Snijders wrote:
>> Thanks for the review and your question. Jumping in as working group
>> participant.
>> 
>>> On Wed, 15 May 2024 at 20:01, Paul Wouters via Datatracker <[e-mail]> wrote:
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> I am not an rPKI expert, so this might be a dumb question. If Key A
>>> generates its CA, and then lets its CA expire, or the expiration
>>> time is smaller than the acceptance window, is there a way to
>>> recover from this? The rules seem to say a new Key B cannot be
>>> created because it wouldn't be accepted ?
>> 
>> The relaying parties have a local copy of the Trust Anchor’s public
>> key (this is called the Trust Anchor Locator). The TAL does not
>> contain expiration information, it only contain a URL where to
>> download the Trust Anchor certificate and the public key to verify
>> the certificate.
>> 
>> If the Trust Anchor’s self-signed certificate expires, or the TAK’s
>> EE certificate expires, the TA operator can simply issue a new TA
>> certificate or new TAK that’s not expired.
>> 
>> If expiration happens during the acceptance window, the whole
>> process needs to start anew, a new TAK for B would need to be
>> issued.
>> 
>> Does this help clarify?
> 
> In addition to the above, there is guidance in the 'Acceptance Timers'
> section
> (https://www.ietf.org/archive/id/draft-ietf-sidrops-signed-tal-15.html#name-acceptance-timers)
> that is relevant to this scenario (though that section is in terms of
> removal of a successor key from a TAK object, rather than expiry of
> the TAK object).  The TA should change the URLs for the successor
> public key when the new TAK object is issued, so as to increase the
> chance of RPs switching over at about the same time.  (If the URLs
> aren't changed, and an RP does not attempt to validate during the time
> when the TAK object or TA certificate is expired, then when the TAK
> object or TA certificate is renewed, that RP's acceptance timer won't
> be affected.  Changing the URLs will cause the acceptance timer to
> reset.)
> 
> -Tom