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
