Re: [Trans] Clarification needed

[Eran Messeri <[e-mail]>]

On Tue, Aug 5, 2014 at 10:10 PM, Rick Andrews <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>
>