Opened 7 years ago

Closed 7 years ago

#105 closed enhancement (fixed)

Shrink LogID

Reported by: rob.stradling@… Owned by: rob.stradling@…
Priority: major Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:
Cc:

Description

SCTs currently contain...

struct {

opaque key_id[HASH_SIZE];

} LogID;

That's 32 bytes (assuming SHA-256) just to give clients a hint about which log public key should be used to verify the SCT signature. Wasteful.

Also, I don't see why it needs to be a "struct".

There are various schemes we could use, but here's my proposal...

  1. Redefine LogID to...

opaque LogID<1..28-1>;

  1. Change... '"key_id" is the HASH of the log's public key, calculated over the DER

encoding of the key represented as SubjectPublicKeyInfo?.'

...to...
'"LogID" is the DER-encoding of an OID, excluding the ASN.1 tag and

length bytes, that the log operator has allocated for the purpose of
uniquely identifying this log.'

  1. Add the LogID OID to the log metadata.

Any better ideas?

Change History (12)

comment:1 Changed 7 years ago by rob.stradling@…

The ASN.1 tag byte can be omitted in my proposal because we'd know it's an OID from the context, and the length byte(s) can be omitted because <1..28-1> already tracks the variable length for us.

comment:2 Changed 7 years ago by rob.stradling@…

Alternative idea: Use a truncated hash of the log public key as the LogID. How many bits would be needed?

comment:3 follow-up: Changed 7 years ago by eranm@…

I found that the use of the key's hash as the log ID very useful when implementing RFC6962: There is no disambiguity regarding the issuing log, there are no chances of discrepancy between key and log ID and no chance of missing log metadata hampering signature validation (the only piece of information a client absolutely needs to know about a log is its key).

For this reason I don't support the suggestion of using an OID.
Truncating the hash sounds more reasonable.

comment:4 in reply to: ↑ 3 Changed 7 years ago by rob.stradling@…

Replying to eranm@…:
<snip>

For this reason I don't support the suggestion of using an OID.
Truncating the hash sounds more reasonable.

I'm minded to agree to you, Eran.

If LogID is an OID (or indeed anything that's not derived from the log public key), a log operator might be tempted to set up multiple logs that have different LogIDs but that use the same keypair. That sounds like a bad idea to me, so I think it'd be best to avoid opening up that possibility.

How many bits of truncated hash is enough? 32 bits?

comment:5 Changed 7 years ago by benl@…

If the ID is too short, you fail to meet the "no chance of discrepancy between ID and key" goal. 32 bits is certainly too short to be comfortable about that.

comment:6 Changed 7 years ago by rob.stradling@…

I just chatted to Ben. We're inclined to stick with the OID proposal (see Description of this ticket).

Let's also add some text along the lines of:
"A log MUST NOT use the same keypair as any other log"

comment:7 Changed 7 years ago by eijdenberg@…

How many bytes would a typical OID encoded as described be?

comment:8 follow-up: Changed 7 years ago by carl.mehner@…

Hi Adam, it really depends on the OID that the log operator is able to allocate for their log. The smallest would be around 3 bytes without the ASN.1 tag. However, they can be much longer, the OID for sha256WithRSA is 9 bytes while CT's SCT OID is 10 bytes without the ANS.1 tags.

You can see a visual here (oid related bytes are colored gold):
http://www.cem.me/20150121-cert-binaries-3.html

comment:9 Changed 7 years ago by eijdenberg@…

Thanks - and reading up it looks like anyone can easily create an OID based on a UUID (e.g. for testing) without needing to go and register it anywhere.

So by way of example, http://www.itu.int/en/ITU-T/asn1/Pages/UUID/generate_uuid.aspx gave me:

ea203d20-5736-11e5-96b8-0002a5d5c51b

with an OID equivalent of:

2.25.311206744302421014316069734894592705819

which encodes (using https://www.viathinksoft.com/~daniel-marschall/asn.1/oid-converter/online.php) as:

06 14 69 83 D4 A0 9E C8 8A F3 B0 C7 CB 96 DC 80 80 AA AE D7 8A 1B

The first two bytes of which we can strip, leaving us with 20 bytes.

comment:10 in reply to: ↑ 8 Changed 7 years ago by rob.stradling@…

Replying to carl.mehner@…:

Hi Adam, it really depends on the OID that the log operator is able to allocate for their log. The smallest would be around 3 bytes without the ASN.1 tag.

I'm optimistic that we'll be able to find an organization that owns a 1.3.<X> OID arc (where X<=127) and that will be willing to either:

  1. delegate a single 1.3.<X>.<Y> subordinate arc (where Y<=127) so that any log will be able to request a 1.3.<X>.<Y>.<Z> OID. (Without the ASN.1 tag and length, that would be 4 bytes for the first 128 logs, then 5 bytes thereafter).

or

  1. delegate a portion of the OID range 1.3.<X>.<0..16383>. (Without the ASN.1 tag and length, that would be 4 bytes for many more than just the first 128 logs, and maybe even 3 bytes for the first few logs).

comment:12 Changed 7 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.