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

Ryan Sleevi <> Fri, 30 July 2021 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 556973A11EA for <>; Thu, 29 Jul 2021 17:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Status: No, score=-1.644 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 8VubU_8E_s7V for <>; Thu, 29 Jul 2021 17:25:11 -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 337873A11E5 for <>; Thu, 29 Jul 2021 17:25:11 -0700 (PDT)
Received: by with SMTP id j18-20020a17090aeb12b029017737e6c349so7178079pjz.0 for <>; Thu, 29 Jul 2021 17:25:11 -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=e4kDf6qXZB2ZNghsIThjBJNCLp1rtwV0tq5yeb3FuBQ=; b=SZhpdbT1KJJ3Yjy0iATZ0O6B4ojVXnRdjh+BnkcM1Fj6Gt/rgL4DA2rAg3eV83+Re3 TWN97l7PqPV7JbIIYLybP399m1lJhWMHGOM2JOX/ZNpaQEYth1hOpBBQeI1tnqPABIRL gCm+hTGTxHk+GjDqWuKBcdnqKR3KeyhLAEYDPzU+kifHA99fUSSVAbM6lZ58shk1Updk gZ7meiQFqP+W1S89B2LmbKhM1pCjpfeHbbstvvHdqS5eZbDQ1Gd8vRGFcQqQCUw9eNir oEJ+vBusjF8UAkA0gKjZoS7IevEFTAv9ghEo95/KTRwH9GJU1KAOse3kiOyP86+DIRZG po5Q==
X-Gm-Message-State: AOAM5307+swHe8Nz+1K+EvOtvXeHS3Jk37GsQJSYeBNse8163hvNXnB/ vky3WhN1d0rDoW+6NVFr6SA9QPwFoz4=
X-Google-Smtp-Source: ABdhPJxXFOonh7HhcNbesBNtpiKi6/c/kb7ZJEKywQvXXAML2U4UsRSrmjp5KppXbm6OXoKYnzhk+w==
X-Received: by 2002:a63:e155:: with SMTP id h21mr1929996pgk.209.1627604710036; Thu, 29 Jul 2021 17:25:10 -0700 (PDT)
Received: from ( []) by with ESMTPSA id k19sm3881156pgt.37.2021. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 17:25:09 -0700 (PDT)
Received: by with SMTP id e5so8948602pld.6 for <>; Thu, 29 Jul 2021 17:25:09 -0700 (PDT)
X-Received: by 2002:a17:90a:9205:: with SMTP id m5mr112173pjo.172.1627604709428; Thu, 29 Jul 2021 17:25:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 29 Jul 2021 20:24:58 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "Salz, Rich" <>
Cc: Martin Duke <>, Ryan Sleevi <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008a54ca05c84c40e0"
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: Fri, 30 Jul 2021 00:25:15 -0000

On Thu, Jul 29, 2021 at 6:06 PM Salz, Rich <> wrote:

>    - So returning to my previous point, it seems rather heavyweight to
>    update the IANA registry every time this happens, and it would arguably be
>    efficient to assign a given operator a range so that these need not be
>    deconflicted in perpetuity?
> The registry is only for those organization that don’t have an OID arc of
> their own.

A correction here: The registry defined by CT for anyone - including those
who hold their own PEN.

That is,
exists as a size optimization.

CT today (6962) currently uses the SHA-256 hash of the log key - so takes
32 bytes.
Using Google's PEN as an example (since every new PEN will be longer),
Google's PEN is, which takes 9 bytes. Plus the usual
byte-per-arc for organization.
Using the LogID registry, the first 8K logs (since it's FCFS, same as PEN)
can get away with just 4 bytes.
The next 128 can also get away with 4 bytes, while those remaining get
increasingly longer, starting at 5 bytes.

This saves a few bytes per SCT, which saves several bytes per certificate
(with embedded SCT). The IETF security areas have a history of allocating
short OIDs to allow for efficient encoding, e.g. through the donation of
organizations who, for historic purposes, have shorter OIDs than otherwise
obtainable today through PENs.

That's the case here: Thawte ( ) - or more
aptly, DigiCert, who acquired Thawte by way of acquiring Symantec by way of
acquiring VeriSign... and so forth - has graciously donated the use of
their OID space to promote shorter encodings, effectively using a portion
of their namespace as "PENs, but for Log IDs". To ensure that's managed
without conflict, IANA is asked to manage it - the same as they manage
PENs. Unlike PENs, requesters only get a single OID for the Log - although
they can request many at once - since the whole point is "fewer arcs, more
efficient encoding"

Hopefully this explains a bit more the context?

You're absolutely right that no one has to use this, they can always use a
PEN if they want to not have to coordinate new logs with IANA action - but
the benefit of that small IANA overhead is a (relatively) substantial
savings in encoding overhead for the log ID, over the certificate hash.

Hopefully this captures for Martin the context as to why it's a valuable
thing, and how the IANA action is hopefully not too heavyweight for the log

That said, if the concern is IANA's management overhead, that's good to
make explicit. I think it's still likely that we'd see the same clever
scheme above, but if the current text needed to get pulled, I think it'd
just end up that the spec just says "use an OID", and DigiCert runs the
list and allocates OIDs themselves. However, if they decide that's too much
hassle, we may all lose out on the efficient encoding, so it'd be a shame.

I do agree with your PR, but in terms of expectations, I think we'll see
the majority of log operators explicitly preferring the Log ID approach
because of the efficient encoding