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

From: Andrew Ayer <[email-masked]>
Date: Thu, 4 May 2017 08:25:53 -0700

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 4 May 2017 14:24:51 -0400

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-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Eran Messeri <[email-masked]>
Date: 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 <[email-masked]> wrote:

> TBH, I don't feel very strongly about this.  Andrew's analysis seems
> pretty sound.
>

---

From: Linus Nordberg <[email-masked]>
Date: Fri, 12 May 2017 15:55:51 +0200

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 <[email-masked]> wrote
Fri, 12 May 2017 14:27:04 +0100:

>>> Regarding https://github.com/google/certificate-transparency-rfcs/pull>> /248
>>>
>>> https://www.ietf.org/mailman/listinfo/trans>>
>>
>>
>> https://www.ietf.org/mailman/listinfo/trans>
>>

---

From: Rob Stradling <[email-masked]>
Date: Fri, 19 May 2017 17:19:03 +0100

> '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.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
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.

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 22 May 2017 16:27:48 +0200

Rob Stradling <[email-masked]> wrote

> the Submitter can't guarantee that the log will accept the submission

No objection.

> Rather than an "is_precertificate" parameter, how about adding a
> "type" parameter that takes a VersionedTransType integer value?

Support.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 May 2017 12:35:09 -0400

> > submission that 6962-bis cares about.

This all sounds fine to me.