On Tue, Aug 5, 2014 at 10:10 PM, Rick Andrews <[email protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
