Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-00.txt

From: [email-masked]
Date: Mon, 13 Nov 2017 23:20:18 -0800

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-00.txt
	Pages           : 10
	Date            : 2017-11-13

Abstract:
   Trust Anchor Locators (TALs) [RFC7730] 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 published by
   Trust Anchor to communicate a new TAL to already deployed Relying
   Parties.  The two primary use cases for this are that 1) a Trust
   Anchor may wish to change the locations where its TA certificate may
   be found, and 2) a Trust Anchor may wish to perform a planned
   migration to a new key.  Note that unplanned key rolls are considered
   out of scope for this document.

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-00
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-00

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/

---

From: Tom Harrison <[email-masked]>
Date: Thu, 16 Nov 2017 18:34:41 +0800

> 	Filename        : draft-ietf-sidrops-signed-tal-00.txt

We've done a fairly basic proof-of-concept implementation of this as
an extension to our RPKI system.  The core of it looks good and
functions as expected.  Some questions and minor suggestions (all
IMHO):

Having explicit structure in the SignedTalContent definition would
make implementation a little easier.  It would also remove any
possible confusion about whether the public key need be base64-encoded
again (the current text appears to require that).

Section 3.3 has "[i]f the above procedure indicates that the manifest
is invalid".  It looks like it should be "...that the Signed TAL is
invalid".

Section 4 has "[t]his EE certificate MUST have a "notBefore" time that
is before the moment that the Signed TAL will be published".  Why is
this a MUST?  I can imagine somebody prepublishing the new TAL, but
not wanting RPs to switch over until the notBefore time had been
reached, though I guess that would also lead to validation errors for
RPs in the interim due to the object not being in-date.

Regarding signed TAL EE certificate validity periods generally, I
think it would be good to add some text about how the new TAL becomes
'effective' as soon as it is published, and that neither revocation
nor expiry of the associated EE certificate has any implications in
that respect (even though this is implicit from the document as a
whole).

Section 6.3 has "[t]he TA SHOULD preserve a Signed TAL for the old key
after the staging period as a hint for RPs that missed the key roll".
Although (I think) the only sensible way to read this is that the
signed TAL to which this is referring is that pointing to the new TA,
"for the old key" might make people think the signed TAL should be for
the deprecated key instead.  Something like "[t]he TA SHOULD preserve
the Signed TAL pointing to the new TA after the staging period..."
could work.

I think 24 hours for the staging period is too short, mainly because
people who don't update their validators to support this may not take
action on the new validation error (something like "unknown type of
object: {name}.tal") within that short a time period.  There are also
other instances like this where manual action might be required, e.g.
where operations staff insist that the validator not have write access
to its configuration and that all updates happen manually.  A week or
a month as a mandatory period would be better.

-Tom