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

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jul 2021 20:30:04 +0000

Sorry for losing the original message and therefore the References, etc., headers.

  *   Thanks for this document; I found it very interesting and enjoyed working
  *   through the Merkle Tree algorithms.

You are a glutton for punishment.

  *   1. I have some concerns about the scalability of this proposal and the Log ID
registry. If I understand correctly, there are at least two reasons an operator
would choose to shut down their log and start a new one, which requires a new
log ID:

  *   - to refresh the signature algorithm and/or key

The signature algorithm is unlikely to change until we have to deal with post-quantum signatures, and that is years away. As for the key being rotated, this is not a short-term WebPKI TLS key, but rather a long-term data signing key. So far none of the logs being used (I hesitate to say “in production”) have had to do either.

  *   - As certificates expire and are renewed over time, the log has to retain an
ever-expanding listing of useless, expired certificates and chains. While the
Merkle tree makes this computationally inexpensive, pruning the storage
requirements would require a refresh.

Perhaps. But again, it hasn’t happened yet, and there are multiple logs that record all of LetsEncrypt output, all the certs currently found on the Web via crawling, and so on.

  *   Which is to say that log IDs should change quite frequently.

As I’ve tried to show above, this seems not to be the case.  Certainly none of the logs currently being used have had to do it. (Yes, some used a different ID when going from “practice” to “deployment,” but that’s a different matter.)

  *   2. Would it be valuable to have a new "certificate revoked" object type in logs
that could provide some assurance that entries hadn't been revoked? I can think
of some ways this might work, but am not familiar enough with the use cases to
say if it'd be valuable.

Revocation in the WebPKI doesn’t work; instead clients do OCSP status checks to see if the certificate is still valid. That is a separate problem from what TRANS is doing, knowing if the certificate was properly issued.

>3. One nit: 4.1.1 and 4.1.2 have broken markdown tags.

Ben Kaduk fixed this.  Tnx.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 17:10:23 -0400

On Thu, Jul 29, 2021 at 4:30 PM Salz, Rich <rsalz=
[email-masked]> wrote:

> The signature algorithm is unlikely to change until we have to deal with
> post-quantum signatures, and that is years away. As for the key being
> rotated, this is not a short-term WebPKI TLS key, but rather a long-term
> data signing key. So far none of the logs being used (I hesitate to say “in
> production”) have had to do either.
>

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.

For example, it's a policy requirement for present CT enforcing agents that
logs be temporally sharded, such that a log does not accept certificates
that expire after a defined point, so that the log can be retired after
that point.

Effectively, the log ID space is as wide as the private key space. The
switch from (key hash) to OID largely removes the dependency on both the
hash algorithm and can reduce the size of the ID. The existence of the
registry is simply to allow for smaller encoding than using a Private
Enterprise Number, as stated in the draft. That is, the registry is simply
a form of compression :)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jul 2021 21:15:42 +0000

*   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?  And do we need to give Log’s not an ID but rather an arc?

---

From: Martin Duke <[email-masked]>
Date: Thu, 29 Jul 2021 14:19:44 -0700

Hi Rich,

I was almost sure we had this exchange, and yet I can't find it in my email
archives. Anyway:

Regardless of the outcome of this LogID discussion, I do not object to you
making changes (or not) as you see fit, having considered my comments.

Thanks for the response
Martin

On Thu, Jul 29, 2021 at 2:15 PM Salz, Rich <[email-masked]> 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.
>
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 17:36:12 -0400

On Thu, Jul 29, 2021 at 5:15 PM Salz, Rich <[email-masked]> wrote:

> 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 -
https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-40.html#name-log-id
- 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
identical"

---

From: Martin Duke <[email-masked]>
Date: Thu, 29 Jul 2021 14:44:42 -0700

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?

On Thu, Jul 29, 2021 at 2:36 PM Ryan Sleevi <[email-masked]> wrote:

> The draft flags that the communication of LogIDs is fundamentally
> something that is done out-of-band -

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 17:50:37 -0400

> deconflicted in perpetuity?

Isn’t that just reinventing PENs under a shorter arc, at that point?

In practice, what we see is log operators creating multiple logs at once
(e.g. for six annual shards), and then updating annually or semi-annually
to add new temporal shards.

So I’m not sure which part of the heavy handed is being optimized for,
mostly due to ignorance on my part: is the concern this is process
intensive on the IANA part, or the log operator part? If the log operator
sees this as intensive, then they’ve got the PEN route as a readily
deployable alternative (at the cost of larger messages). If it’s overhead
on the IANA part, then that would seem to argue scrapping the whole “too
clever and a half” idea of “use a short OID because, for historic reasons,
IANA has some”, and just pay the 4-10byte tax for using PENs.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jul 2021 22:06:12 +0000

*   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.  Getting one is pretty easy, one possibility is requesting it at https://pen.iana.org/pen/PenApplication.page  We could add that to the doc if you think it would be useful.  You get what’s called an “arc” and then you append .1, .2, .3.1, etc., as you want.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jul 2021 23:32:09 +0100

On 29/07/2021 23:06, 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. Getting one is pretty easy, one possibility is 
> requesting it at https://pen.iana.org/pen/PenApplication.page 
> <https://pen.iana.org/pen/PenApplication.page>
>
Which is First Come First Served registry, which is a rather low bar.
>
> We could add that to the doc if you think it would be useful.  You get 
> what’s called an “arc” and then you append .1, .2, .3.1, etc., as you 
> want.
>
Indeed. Org arc only need to be allocated once and can be used for all 
sort of other protocols as well.

---

From: Martin Duke <[email-masked]>
Date: Thu, 29 Jul 2021 15:32:56 -0700

SGTM.

On Thu, Jul 29, 2021 at 3:32 PM Alexey Melnikov <[email-masked]>
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
> The registry is only for those organization that don’t have an OID arc of
> their own.  Getting one is pretty easy, one possibility is requesting it at
> https://pen.iana.org/pen/PenApplication.page
>
> what’s called an “arc” and then you append .1, .2, .3.1, etc., as you want.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jul 2021 22:44:54 +0000

Added this text:
+One way to get an OID arc, from which OIDs can be created, is to request
+a Private Enterprise Number from IANA, by completing the
+[registration form](https://pen.iana.org/pen/PenApplication.page).

At https://github.com/google/certificate-transparency-rfcs/pull/341

From: Martin Duke <[email-masked]>
Date: Thursday, July 29, 2021 at 6:33 PM
To: Alexey Melnikov <[email-masked]>
Cc: Rich Salz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

SGTM.

On Thu, Jul 29, 2021 at 3:32 PM Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

The registry is only for those organization that don’t have an OID arc of their own.  Getting one is pretty easy, one possibility is requesting it at https://pen.iana.org/pen/PenApplication.page<https://urldefense.com/v3/__https:/pen.iana.org/pen/PenApplication.page__;!!GjvTz_vk!HWyU0WX7goBE_4CUTk4VYHTqzjPMzA1bGSLCiBEEmLYytv5zZMbuiG29vSps$>
Which is First Come First Served registry, which is a rather low bar.
We could add that to the doc if you think it would be useful.  You get what’s called an “arc” and then you append .1, .2, .3.1, etc., as you want.
Indeed. Org arc only need to be allocated once and can be used for all sort of other protocols as well.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jul 2021 20:24:58 -0400

On Thu, Jul 29, 2021 at 6:06 PM Salz, Rich <[email-masked]> wrote:

> their own.

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

That is,
https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-40.html#name-log-ids-registry
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 1.3.6.1.4.1.11129, 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 ( http://oid-info.com/get/1.3.101 ) - 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
operator.

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Jul 2021 23:38:19 -0400 (EDT)

On Thu, 29 Jul 2021, Ryan Sleevi 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?
> 
> 
> In practice, what we see is log operators creating multiple logs at once (e.g. for six annual shards), and
> then updating annually or semi-annually to add new temporal shards.
> 
> So I’m not sure which part of the heavy handed is being optimized for, mostly due to ignorance on my part:
> is the concern this is process intensive on the IANA part, or the log operator part? If the log operator
> sees this as intensive, then they’ve got the PEN route as a readily deployable alternative (at the cost of
> larger messages). If it’s overhead on the IANA part, then that would seem to argue scrapping the whole
> “too clever and a half” idea of “use a short OID because, for historic reasons, IANA has some”, and just
> pay the 4-10byte tax for using PENs.

Martin,

Thanks for your thorough review and voluntary Merkle Tree diving.

It seems the above answers your question. Log operators have a choice on
how to get their unique log ID(s). They can get a larger assignment and
use numbers within their assignment trivially, so there is no problem
of something being too "heave handed" I believe. They don't have to use
IANA if they already have their own OID space, and if they don't they
can easilly get a suitably large assignment by a one-time action.

I think we are really late into the game to go and change anything
related to this now, especially as we have seen years of no issues with
RFC 6962 and log IDs. As you stated your comment was "non-blocking",
we will consider this comment resolved.

Thanks,

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Jul 2021 23:53:27 -0400 (EDT)

Alexey,

I see you still have a DISCUSS open, but I believe this item was already
fully resolved:

 	I think this is an important document and I am looking forward to seeing it as a Proposed Standard in the future.
 	However, it has a good number of editorial issues that make the document hard to read and implement.

 	5.  Log Client Messages

 	type:  A URN reference identifying the problem.  To facilitate
 	automated response to errors, this document defines a set of
 	standard tokens for use in the "type" field, within the URN
 	namespace of: "urn:ietf:params:trans:error:".

 	I think you need to register this in <https://www.iana.org/assignments/params/params.xhtml#params-1>

 	Also, can you clarify whether error need an IANA registry?

The error IANA registry is present at, https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-40#section-10.1.2

Can you confirm this resolves your DISCUSS?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Jul 2021 00:00:16 -0400 (EDT)

Hi Adam,

We believe the latest version which included the change of registries
from Expert Review to Specification Required resolves all your COMMENTs.

https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-40#section-10

Earlier updates had already fixed the boiler plate to use RFC 8174 text
and the use of "we have established".

Please let us know if you feel your COMMENTs have not been fully
addressed.

Paul