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

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 <eranm@google.com> 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 <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>
>>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans