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

It occurs to me that ... we should have closed out the wglc for this
document prior to IETF week.
If this set of comments/edits is all done then we can send a new version of
the draft and forward things up the mgmt chain.

thoughts?

-chris

On Tue, Jul 17, 2018 at 5:52 PM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:

> Hi Tom,
>
> Thanks for testing and the feedback. Comments below.
>
> > On 17 Jul 2018, at 12:58, Tom Harrison <tomh@apnic.net> wrote:
> >
> > On Fri, Jun 08, 2018 at 06:30:41AM -0700, 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
> >
> > I've updated our proof-of-concept to match the new draft.  Some
> > questions and minor suggestions:
> >
> > In section 3, there is:
> >
> >   The ASN.1 syntax for the Signed TAL eContent defined in
> >   Section 3.2.  (This is the payload that specifies the AS being
> >   authorized to originate routes as well as the prefixes to which
> >   the AS may originate routes.)
> >
> > The text in parentheses looks to be a cut-and-paste from the ROA
> > profile document (RFC 6482).
>
> Fixed in my edit buffer.
>
> > In section 4, there is "[t]his EE certificate MUST have a 'notAfter'
> > time that reflects the intended time that this Signed TAL will be
> > published", which on its face implies that the 'notAfter' should be
> > set to the time when the object is first published.  Changing it to
> > "reflects the intended time [or duration] for which this signed TAL
> > will be published" should make things clearer.
>
> Yes, you are right. The intention was duration. Fixed in the edit buffer.
>
> >
> > The SubjectPublicKeyInfo in the TAL structure has the type IA5String.
> > Is there some reason not to use the 'raw' SubjectPublicKeyInfo type
> > from RFC 5280?
>
> This is an oversight. It should just be the raw DER structure.
>
> > Since activationTime is not needed for an in-protocol reason at the
> > moment, it would be good to add a note to the draft that it's there to
> > prompt discussion/feedback about future dating.
> >
> > On future dating more generally, I think it's a good idea, since it
> > allows for in-band signalling about the rollover and would (hopefully)
> > encourage a wider set of users to test the new tree before it becomes
> > the 'official' tree.
>
> The current draft assumes that the TA tests things before publishing the
> new signed TAL object, and then I think it would be okay for RPs to follow
> this new TAL as soon as it’s available.
>
> But.. there may be good reasons for future dating / having a backup key.
>
> In that case I would suggest that we have a structure where the ‘current’
> TA key and URIs are always listed explicitly, pretty much like the document
> says now, but there is an optional similar structure with the intended
> ‘activationTime’ (informational only) for the new key.
>
> That way the roll can be prepared in advance. RPs could theoretically
> verify independently that things are okay - but I would like to avoid
> putting this burden on all RPs. Once things are okay to roll, the TA can
> update it’s signed TAL then to make the new key ‘current’ and RPs can
> follow.
>
> As I said at the mic HSMs can be used to protect against key theft. But
> keys (or card sets) can still be lost. If access to the new key is lost,
> then the TA can just choose not complete the roll - remove it, replace it
> with a new target key. If access to the current key is lost, then things
> get more difficult. Then the new key would have to be allowed to take over,
> e.g. automatically once the activation time is past?
>
> Explicit revocation of the old key is also possible, but would require
> that RPs constantly check these candidate keys. I am afraid this adds a lot
> of overhead.
>
> Comments and ideas are most welcome!
>
> Tim
>
>
>
>
>
>
> >
> > -Tom
> >
> > _______________________________________________
> > 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
>