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
