Re: [Trans] Consolidating add-chain and add-pre-chain endpoints

(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 <rlb@ipv.sx> 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 <agwa@andrewayer.name> 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
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>