Subject: [Trans] Clarification needed

From: Rick Andrews <[email-masked]>
Date: Tue, 5 Aug 2014 14:10:45 -0700

In thinking about how log servers should behave, I came up with two cases that should probably be addressed in the -bis so that all log servers behave the same way.

1) Let's say I've issued a cert and embedded the SCTs in the cert. Now I (or someone else) send the cert to log servers using the add-chain command. What happens? Should the log server see if one of the SCTs is from itself, and if so just return that SCT? Or should it generate a new SCT?

Rob Stradling helped me understand that the SCTs in the cert would have a "entry_type" of "precert_entry", so the log server shouldn't just return that. Instead, it seems that it should create a new SCT with an "entry_type" of "x509_entry". But it's worth clarifying that this new SCT would contain a hash over the entire cert, including the existing SCTs, even if one of those embedded SCTs originated from that same log server.

2) Finally, is it worth clarifying that while anyone can invoke the add-chain command, only CAs are expected to invoke the add-pre-chain command? Should log servers return an error if the pre-cert presented in the add-pre-chain command does not contain the poison extension?

Finally, it might be worth clarifying Section 4.2, Add PreCertChain to Log, where the input is described as "An array of base64-encoded Precertificates", which seems to imply that the CA can send multiple pre-certs and chains in a single command. The rest of the description makes it clear that the log server expects only one chain, the first cert in the chain is the pre-cert and the following certs are the (non-pre-cert) certs in the chain.

It's not clear to me if I should create issues in the tracker for these. I thought I would get some initial feedback first.

-Rick

---

From: Eran Messeri <[email-masked]>
Date: Tue, 5 Aug 2014 22:25:25 +0100

On Tue, Aug 5, 2014 at 10:10 PM, Rick Andrews <[email-masked]>
wrote:

>  In thinking about how log servers should behave, I came up with two
> cases that should probably be addressed in the –bis so that all log servers
> behave the same way.
>
> 1) Let’s say I’ve issued a cert and embedded the SCTs in the cert. Now I
> (or someone else) send the cert to log servers using the add-chain command.
> What happens? Should the log server see if one of the SCTs is from itself,
> and if so just return that SCT? Or should it generate a new SCT?
>
> Rob Stradling helped me understand that the SCTs in the cert would have a
> "entry_type" of "precert_entry", so the log server shouldn’t just return
> that. Instead, it seems that it should create a new SCT with an
> "entry_type" of "x509_entry". But it’s worth clarifying that this new SCT
> would contain a hash over the entire cert, including the existing SCTs,
> even if one of those embedded SCTs originated from that same log server.
>
Good point - it's completely valid to send a certificate with embedded SCT
from one log as an x509_entry certificate to other logs to obtain
additional SCTs. The RFC should be explicit about this situation.

>
> 2) Finally, is it worth clarifying that while anyone can invoke the
> add-chain command, only CAs are expected to invoke the add-pre-chain
> command? Should log servers return an error if the pre-cert presented in
> the add-pre-chain command does not contain the poison extension?
>
Yes - and the reference open-source implementation already returns an error
if the poison extension is not present:
https://github.com/google/certificate-transparency/blob/master/cpp/log/cert.cc#L879

(coincidentally, the open-source implementation will also return an error
if the poison extension *is* present in a certificate added by add-chain
rather than add-pre-chain).

>
> Finally, it might be worth clarifying Section 4.2, Add PreCertChain to
> Log, where the input is described as “An array of base64-encoded
> Precertificates”, which seems to imply that the CA can send multiple
> pre-certs and chains in a single command. The rest of the description makes
> it clear that the log server expects only one chain, the first cert in the
> chain is the pre-cert and the following certs are the (non-pre-cert) certs
> in the chain.
>
> Excellent observation - there's an errata for RFC6962 exactly for this
wording:
http://www.rfc-editor.org/errata_search.php?rfc=6962

>
>
> It’s not clear to me if I should create issues in the tracker for these. I
> thought I would get some initial feedback first.
>
I suggest you do - definitely for (1), I've created one
<http://trac.tools.ietf.org/wg/trans/trac/ticket/45> for (3)( as the errata
should be incorporated into -bis).

>
> -Rick
>
>
>
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>