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

[Rob Stradling <[e-mail]>]

On 12/05/17 14:55, Linus Nordberg wrote:
> I like the single add-entry call idea together with the explicit
> 'is_precertificate' indication.

Would "submit-entry" be a better API name than "add-entry" (given that 
the Submitter can't guarantee that the log will accept the submission 
and add it to its tree)?

(Attempt at future-proofing)
Rather than an "is_precertificate" parameter, how about adding a "type" 
parameter that takes a VersionedTransType integer value?
i.e., x509_entry_v2(1) or precert_entry_v2(2), for the two types of 
submission that 6962-bis cares about.

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/trans>>
>>>
>>>
>>> _______________________________________________
>>> Trans mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/trans>
>>>
>> _______________________________________________
>> Trans mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
> 
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
> 

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.