Subject: Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Oct 2015 14:34:24 -0400

Ben,
>
> ...
>
> This is true even if you use hashes, surely? For example, an old key 
> (from a log no longer known to someone) could be reused. Or a key for 
> a log that was never used publicly. Or the same key could be used for 
> two logs accepted by different clients. And so on.

I would expect a Monitor to keep track of the public key for each log 
operator
that it watches, (but that should be stated explicitly). Thus re-use of 
an old key
by that log operator, for a new log instance, would be detected easily 
if the log
ID were derived from the public key. The most common case, if the re-use 
is accidental,
is probably starting a new log instance but not remembering to change 
the key. That would
be obvious/impossible if the ID were derived from the key.

However, I agree that a log re-using a key from some other log would not be
detected by this approach.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Thu, 8 Oct 2015 15:10:29 +0100

On 05/10/15 19:34, Stephen Kent wrote:
> operator that it watches, (but that should be stated explicitly).

Yes.

> Thus  re-use of an old key by that log operator, for a new log instance,
> wouldbe detected easily if the log ID were derived from the public key.

That seems like a non sequitur to me.

Since a monitor has a copy of every log's public key, it can compare 
these public keys to ensure that each one is used by only 1 log.

Or, since it knows each public_key, the monitor could calculate 
HASH(public_key) all by itself and then check the uniqueness of each.

It makes no difference whether LogID is defined as HASH(public_key), an 
OID, or something else.

> The most common case, if the re-use is accidental,

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Oct 2015 09:52:05 -0400

Rob,
> Since a monitor has a copy of every log's public key, 

a Monitor has a copy of every public key for every log that _it 
watches_, and perhaps
only since it began watching the log.
> it can compare these public keys to ensure that each one is used by 
> only 1 log.
only for the logs it watches.
> It makes no difference whether LogID is defined as HASH(public_key), 
> an OID, or something else.
I expect that the most common way that a "new" log would fail to switch 
to a new
key pair is by reusing the same pair it had been using most recently, 
i.e., an error, not
a malicious action. if so then using a key hash as an ID should make it 
very obvious
when this sort of error occurs.

Anyway, I don't think we need to continue to debate this. If you and other
developers are happy with the OID approach, so be it.

Steve

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 28 Oct 2015 11:32:09 -0000

#105: Shrink LogID

Changes (by [email-masked]):

 * status:  new => assigned
 * milestone:   => review

Comment:

 Fixed by https://github.com/google/certificate-transparency-
 rfcs/commit/22746c1a6197c665c7e8ff5d8008c5ab9c7c3537 and
 https://github.com/google/certificate-transparency-
 rfcs/commit/36fc450994792376eccd877bf1b38662142b0705

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  enhancement              |      Status:  assigned
 Priority:  major                    |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:11>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 28 Oct 2015 21:05:50 -0000

#105: Shrink LogID

Changes (by [email-masked]):

 * status:  assigned => closed
 * resolution:   => fixed

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:12>
trans <http://tools.ietf.org/trans/>