I like the single add-entry call idea together with the explicit 'is_precertificate' indication.
The naming here is a bit unfortunate though, at least when compared with PR 256 [1] where 'submission' seems to mean end-entity-(pre)cert _and_ chain. I suggest making the input to an add-entry call and the output from the get-entries call identical, if at all possible. [1] https://github.com/google/certificate-transparency-rfcs/pull/256/files Eran Messeri <[email protected]> wrote Fri, 12 May 2017 14:27:04 +0100: > (follow-up from an out-of-band discussion with Andrew) > The concern Andrew has raised,of some implementations accepting a null > values, it is very valid. Fortunately, it's easy to check that logs do not > behave that way. > > An alternative approach to unifying add-chain/add-pre-chain is to have a > single add-entry call which takes, as inputs: > 'submission' - base64-encoded DER certificate OR CMS Precertificate. > 'chain' - chaining the submission to a root, like now. > 'is_precertificate' - indicating whether the 'submission' parameter should > be parsed as a DER-encoded certificate or CMS Precertificate. > > Any opinions on that? > > Personally I think the concern Andrew has raised is very valid and the spec > should explicitly deal with it, forbidding the presence of an empty > 'precertificate' parameter if a 'certificate' is being supplied, and vice > versa, and logs can easily be checked for compliance with that requirement. > > However I'm also OK with leaving add-chain / add-pre-chain as separate > methods. > > Eran > > On Thu, May 4, 2017 at 7:24 PM, Richard Barnes <[email protected]> wrote: > >> TBH, I don't feel very strongly about this. Andrew's analysis seems >> pretty sound. >> >> On Thu, May 4, 2017 at 11:25 AM, Andrew Ayer <[email protected]> wrote: >> >>> Regarding https://github.com/google/certificate-transparency-rfcs/pull>> >>> /248 >>> >>> I do not think this is a good change. >>> >>> If an implementation wants to use a struct to represent the add-entry >>> message (as Google's Golang CT library currently does), the struct would >>> need to contain nullable variables for the certificate and >>> precertificate fields. Nullable variables are error-prone and are best >>> avoided if possible. >>> >>> For example, a client might accidentally send null as one of these >>> fields instead of omitting it (with Go, this can easily happen if you >>> forget to tag the struct field as omitempty). Although this would be a >>> malformed add-entry message, I expect many servers would accept it >>> because many JSON deserializers I've seen (such as Go's) do not >>> distinguish between a null struct field and an omitted struct field. >>> This risks causing interoperability problems. I expect the predominant >>> 6962-bis log server will be Google's Trillian, which means clients will >>> be interacting mostly with log servers which exhibit the lax >>> deserialization behavior. The client's mistake won't be noticed until >>> it tries to submit a chain to a rarer, stricter server, which might >>> happen long after the client code has been deployed. >>> >>> Therefore, I favor keeping add-chain and add-pre-cert as separate >>> endpoints. That way, the structure of the messages are rigid and >>> clearly indicated by the name of the endpoint. The protocol will have >>> only one joint (the endpoint name) instead of two (the endpoint name >>> plus the presence or absence of the precertificate and certificate >>> fields). >>> >>> Regards, >>> Andrew >>> >>> _______________________________________________ >>> Trans mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/trans>> >> >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans> >> > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
