Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

Ryan Sleevi <> Thu, 29 July 2021 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD52F3A0923 for <>; Thu, 29 Jul 2021 14:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SAT-03gWbuHU for <>; Thu, 29 Jul 2021 14:36:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76EAA3A0918 for <>; Thu, 29 Jul 2021 14:36:24 -0700 (PDT)
Received: by with SMTP id e5so8544405pld.6 for <>; Thu, 29 Jul 2021 14:36:24 -0700 (PDT)
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=+YJwsdc2fEztsKwGZkugzdihCGUT+LgQ9v8dw1sTXmI=; b=VpB7r2xM43AXj9ZVI1rPCUdWSiyeIaNbWsou3RgdwWPEpnkgPVXZZxiWhg2lE95McL SZ4sHVivlm9sHfYPezhuNik7LvgShKThE2rly7sgIE5nX1Tnxhn0sq2Ca1G2S0eD7E5i ajV1NPzce6pSEa6fmZ3XK0UZufUcRqr9UTrEfkInYlfTztmtV7dFNzcRaUFTsZOYIBNW kC5oA92ZoiSW5n3Nzll7YyS/lSwDAxdgqQrNLcsNlXrCy6aoDhPmI55rCLYsHO02gmSF NTFtLRg0nK8QKImMRiSOFOd02wmRxks/VhHv1Jwtcbtyc86944Bm/52PWlGf03kAExPm PCQQ==
X-Gm-Message-State: AOAM532K6f3d6NpjZv/0vgts1iHGd1SbIzSgO+1Yf3Rr2tfWC88Xzt1z u+VfNaMtp3B0g/V90Yrtp8si//eA8hs=
X-Google-Smtp-Source: ABdhPJx6c8PNsuX+H59GXYbYBJfsX6+gMMWGlipe9vaNDfdCelhZvtUIMV1Dfzvb6TBmyEZJpbU3yw==
X-Received: by 2002:a63:dc58:: with SMTP id f24mr5481526pgj.303.1627594583431; Thu, 29 Jul 2021 14:36:23 -0700 (PDT)
Received: from ( []) by with ESMTPSA id l1sm4303856pjq.1.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 14:36:23 -0700 (PDT)
Received: by with SMTP id u9-20020a17090a1f09b029017554809f35so17641776pja.5 for <>; Thu, 29 Jul 2021 14:36:23 -0700 (PDT)
X-Received: by 2002:a63:cd4d:: with SMTP id a13mr5517028pgj.364.1627594583052; Thu, 29 Jul 2021 14:36:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 29 Jul 2021 17:36:12 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "Salz, Rich" <>
Cc: Ryan Sleevi <>, "" <>, Martin Duke <>
Content-Type: multipart/alternative; boundary="000000000000f61ae205c849e432"
Archived-At: <>
Subject: Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jul 2021 21:36:29 -0000

On Thu, Jul 29, 2021 at 5:15 PM Salz, Rich <> wrote:

>    - I'm not sure this is correct, Rich? Logs regularly rotate IDs;
>    presently annually, but it's reasonable to anticipate more frequently as
>    the size/performance tradeoffs, precisely as the way of pruning the storage.
> Thanks for the correction!
> So how do replying parties know the log ID changed?

To be clear, the log ID doesn't change (and refer to the same log). Each
Log ID uniquely identifies a log. For example, if a log changes a key, it's
functionally a new log - this is true in 6962 as it is in 6962-bis. The
only thing that changed in -bis is from identifying logs by key hashes to
identifying by OIDs, which was meant to make for smaller encoding.

The draft flags that the communication of LogIDs is fundamentally something
that is done out-of-band -
- i.e. up to client policy. For example, for two widespread 6962
implementations (Apple's {mac, i, tv}OS and Google's Chrome), the list of
recognized logs is governed by user agent/vendor policy, and those logs are
communicated by the vendor (aka "Trusted Log Lists", although trust is a
bit of a stretch)

> And do we need to give Log’s not an ID but rather an arc?

No. As with 6962, the idea here is not that "This log was ID X, and is now
ID Y" - but rather "I know of a log with ID X, and I now know of a log with
ID Y, and these are logically distinct, even if their contents are