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

George Michaelson <> Thu, 27 February 2020 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33D793A0E4F for <>; Thu, 27 Feb 2020 14:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y-x1l8TDEGAw for <>; Thu, 27 Feb 2020 14:31:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FFDB3A0DE5 for <>; Thu, 27 Feb 2020 14:31:04 -0800 (PST)
Received: by with SMTP id w9so1241703iob.12 for <>; Thu, 27 Feb 2020 14:31:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sVne3KthjmiWuVL/CvB39fTaEy61aVP7nNpL+uf/F7Y=; b=POKXPGS6TtBIIel35e0IRZE2K6+wEFCQ4OFWGWHInRWOa7vG9MvpUwdi647enZR/Jm PZ2T/SjgZLMSozuTTfHJt1VXzlE9vUECSN1gS/evYRvunlE5qEUYXtnru1OXMt7N6lI8 wMd59+4LZ553chapsWM/o8Yp3ZYdP73dzxvQNn4DKZBC4lfoFa9OqxMtgbhVstKdskTD jiOg0H89AeLKrPsWJmClYu3q1wY4PiBMWWgg60ZGfU6iJ7teb6zIf/4MfGyheZO5OikU gbQu0LTskbMfVQNg1ZfAEkSPpa7Oh5bcZvYIocEsXCxPhamJiB0Na8CNXX3mRbDXcOXQ a+bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sVne3KthjmiWuVL/CvB39fTaEy61aVP7nNpL+uf/F7Y=; b=sOJNZhDRPDFrwB91hOwZdoamgY5r19dcxkrReQnvi9Pt1QwMSLZBYfa1cAD1keDowq MiLB0ZV9ETrfNsBhZCo4oY++rVy58kWLhZEzv1UpVYzjZFU3vOYyHFTmtswVeHwWYXDR cwt8sKHLjDNUhfIA1SCbDgZV0ctvS66mNUKdeYBOFYZoHC8ZPYX8iX4ZnQCM9PRxYeoQ 32+zyLypb3XJ9vG02KXnuV2WrQOkZ3TfozGRe/wVw1g41t+6TBsBi0F4HLlZt9aTqadF HOcrt3rPExa7Pr0GfyP4tAwN3Wmkjw/LsbTsrsw/WrmmpupzyxoX6lfFksXLGAV2AIiE i5uA==
X-Gm-Message-State: APjAAAVIInSwsXcODJACbQM5n69ZMzye7JRAkMcKWbuRx946gmFYqd5r OIgKddzMGsN8PoDZz0MCYnksnyWpoEPvud2LsC+lAg==
X-Google-Smtp-Source: APXvYqy2Sfx4QZZBW0sBrjGxQeMfrPnW2yBIbUDQq0/nePJ21456DhSX4NGi3lt2qwGSdVAQMD32nZSK6H4CHKBF0cg=
X-Received: by 2002:a02:cba5:: with SMTP id v5mr937658jap.64.1582842663802; Thu, 27 Feb 2020 14:31:03 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Fri, 28 Feb 2020 08:30:52 +1000
Message-ID: <>
To: Christopher Morrow <>
Cc: SIDR Operations WG <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 22:31:16 -0000

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.


On Fri, Feb 28, 2020 at 4:33 AM Christopher Morrow
<> wrote:
> 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 <> 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:
> >
> >
> > There are also htmlized versions available at:
> >
> >
> >
> > A diff from the previous version is available at:
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at
> >
> > Internet-Drafts are also available by anonymous FTP at:
> >
> >
> > _______________________________________________
> > Sidrops mailing list
> >
> >
> _______________________________________________
> Sidrops mailing list