Subject: Re: [therightkey] Certificate Transparency Version 2

From: Ralph Holz <[email-masked]>
Date: Wed, 01 Aug 2012 17:00:22 +0200

Hi,

On 08/01/2012 12:12 AM, Ben Laurie wrote:
> Many CAs were dismayed by the time it took to issue a "log proof". It
> was also quite a bad name.
> 
> So, in v2 we reduce issuance time to (effectively) zero.
> 
> As always, comments please.

Maybe I'm missing something, or I don't understand your footnote 1
correctly.

But: you state that you create a SCH over the end-host cert and the need
for also hashing and signing the intermediate certs arises because you
want to avoid a CA having the same cert re-issued with a different
intermediate CA (that has the original intermediate CA's private key).

Are you assuming then that, if a CA tried this, the DN in the issuer
field of the end-host cert would be set to the same value again? E.g.,
empty or some standard value and the only SKID/AKID used in
verification? Otherwise, if you insert an intermediate CA that has a
different DN (and maybe key identifier), you'd get a different DER/PEM
and a different hash already.

Or maybe I'm confused. :)

Ralph

-- 
Ralph Holz
Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Ben Laurie <[email-masked]>
Date: Wed, 1 Aug 2012 16:38:40 +0100

On 1 August 2012 16:00, Ralph Holz <[email-masked]> wrote:
> field of the end-host cert would be set to the same value again?

Of course.

> E.g.,
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Ralph Holz <[email-masked]>
Date: Thu, 02 Aug 2012 10:48:16 +0200

Hi,

>> field of the end-host cert would be set to the same value again?

OK, I think I understand. So that would (very likely) be a legitimate
change, i.e. CA changes notbefore/notafter but re-issues cert in same
way. With AKID the same, the end-host cert would not need to be
re-issued, but you still want the proof of exactly that one
certification with that one intermediate cert.

Ralph--
Ralph Holz

---

From: Ben Laurie <[email-masked]>
Date: Thu, 2 Aug 2012 20:54:04 +0100

On 2 August 2012 09:48, Ralph Holz <[email-masked]> wrote:
> way.

This change would require a new entry anyway.

> With AKID the same, the end-host cert would not need to be

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 21 Aug 2012 11:59:48 +1000

Is the DNS scheme in Certificate Transparency v2 <http://www.links.org/?p=1259> scalable?

It mentions TXT records such as:

  <signed-cert-hash>.hash.example.net
  <cert-index>.<level>.<tree-size>.tree.example.net

Sticking with the sample size in the spec of 1.3 million certificates, means there would be 1.3 million DNS entries immediately below .hash.example.net and the same number immediately below .0.1300000.tree.example.net.

That is much smaller than the 100 million entries immediately below .com so it is possible, though it might require more heroics than should be necessary.

<tree-size> is 1300000 in the example. I assume this increments for every certificate logged. This seems to implies you need a whole new DNS tree .1300001.tree.example.net (with ~8.5e11 <cert-index>.<level> sub-entries) when the next certificate is issued! I guess you can synthetically create them on-demand, but that does seem to destroy caching etc.

A DNS scheme that doesn't use <tree-size> as a DNS label (the tree size is still known from the Signed Tree Head), and only publishes the stable parts of the Merkle tree (with stable names) should be possible.

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Ben Laurie
> Sent: Wednesday, 1 August 2012 8:13 AM
> To: [email-masked]
> Subject: [therightkey] Certificate Transparency Version 2
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 21 Aug 2012 11:49:07 +0100

> A DNS scheme that doesn't use <tree-size> as a DNS label (the tree size is still known from the Signed Tree Head), and only publishes the stable parts of the Merkle tree (with stable names) should…

I agree that this ought to be possible - good idea.