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

From: Christopher Morrow <[email-masked]>
Date: Thu, 27 Feb 2020 13:32:20 -0500

Howdy WG Peepls!
This document got marked somewhere in the datatracker as: "WGLC"...
which seems awesome, but I didn't see/remember actually doing that :(

Do the authors feel this document is ready for WGLC? If so we can get
that started :) If not I'll go re-set the status in datatracker.

On Wed, Jan 15, 2020 at 10:29 PM <[email-masked]> 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 Trust Anchor Keys
>         Authors         : Carlos Martinez
>                           George G. Michaelson
>                           Tom Harrison
>                           Tim Bruijnzeels
>                           Rob Austein
>         Filename        : draft-ietf-sidrops-signed-tal-05.txt
>         Pages           : 16
>         Date            : 2020-01-15
>
> Abstract:
>    A Trust Anchor Locator (TAL) [I-D.ietf-sidrops-https-tal] is used by
>    Relying Parties (RP) in the RPKI to locate and validate a Trust
>    Anchor (TA) CA certificate used in RPKI validation.  This document
>    defines an RPKI signed object for a set of Trust Anchor Keys (TAK),
>    that can be used by TA creators and publishers to signal their set of
>    current keys and the location(s) of the accompanying CA certificates
>    to RPs, as well as changes to this set in the form of revoked keys
>    and new keys, in order to support both planned and unplanned key
>    rolls without impacting RPKI validation.
>
>
> 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-05
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-05
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: George Michaelson <[email-masked]>
Date: Fri, 28 Feb 2020 08:30:52 +1000

I'd like it if we could go WGLC. I think it takes a stronger signal of
commit and contentment in the WG. Our author discussion on "where
next" is a bit cold right now, because there isn't much to do, but we
don't have words for what there is to do.

How about we put that to the ML or F2F? Which I guess, is what you just did.

I stole the edit token. I'd be happy to let my esteemed co-authors and
the WG tell me what they want here. Probably, confusion in my part put
it to WGLC but if it is there, why don't we treat it seriously and ask
if its ready?

We need a mechanism to signal intent to change TAL. Automation is a
"step too far" for some people, Rob Kisteleki has spoken to the
inherent risks, and the concern it does not "fix" risks some people
think it may, because an ability to subvert the TAL implies an ability
to subvert the signature over the TAL, and so force communities to
inherit a new TAL, of bad intent. The DNS root process with in-band
signal is a different world. We can learn from it, but it may not show
what general X509 PKI models think is a good way to do this.

Rob suggested we consider why browsers ship TA changes by updating
code. That moves the burden to a body who agrees what TAL need to be
shipped, and liaison with the Validator authors and release processes.

Or, a hand-run process to use this mechanism.

Or, a signalling mechanism to flag "this TAL needs to change" but the
actual decision to change, is hand-managed buy the RP.

Basically, I don't know why it flagged WGLC but I think it is not far
off, and I would like it to close.

-G