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