On 14/10/2019 16:32, Mirja Kuehlewind wrote: > Hi Rob, > > Thanks for your replies and edits. I will clear my discuss as soon as the new > version is submitted.
Thanks Mirja. > Please see some minor comments below! Replies inline. > Thanks! > Mirja > > >> On 14. Oct 2019, at 16:07, Rob Stradling <[email protected]> wrote: >> >> Hi Mirja. Sorry for the looong delay. >> >> Comments inline, and I've just posted this PR: >> https://github.com/google/certificate-transparency-rfcs/pull/316 >> >> On 14/03/2019 13:50, Mirja Kühlewind via Datatracker wrote: >>> Mirja Kühlewind has entered the following ballot position for >>> draft-ietf-trans-rfc6962-bis-31: Discuss >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> There was a presentation at maprg IETF 103 about the question if CT helps >>> attackers to find new domains. I think this risk should at least be >>> mentioned >>> in the security considerations section. >> >> Addressed by >> https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2ec0a51f8abb4c8c0b985614fefa4291432dd9 >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> 1) I found section 2 a bit hard to follow. Would it maybe be possible to >>> provide more textual explanation of the algorithms instead of just >>> describing >>> the steps of the algorithms? Also I was wondering how much much these >>> algorithms are actually „part“ of the protocol spec…? Are could these be >>> rather seen as example algorithms? Maybe that could be further clarified >> >> We'll consider these comments on section 2 at a later date, along with >> Benjamin Kaduk's comments on section 2. >> >>> 2) Please expand STH on first occurrence (in sec 4.1) >> >> Addressed by >> https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6b0ac303af2659e5df538391002f1bf454edb >> >>> 3) Sec 4.4: „A log's operator MUST either allocate the OID >>> themselves or request an OID from the Log ID Registry (see >>> Section 10.6.1).“ >>> Isn't there an obligation to register? >> >> The Log ID Registry is merely a source of OIDs that have short DER >> encodings. A log operator may either (1) request an OID from the Log ID >> Registry, or (2) allocate an OID themselves (from an OID arc that they >> control, naturally). >> >> The Registry is not intended to be a global directory of all logs. > > Could be good to clarify in the text. Addressed by https://github.com/robstradling/certificate-transparency-rfcs/commit/18be3bdc0eb3a8f5b95040081ccfaddcd2924fcb >>> 4) sec 4.8: „If an >>> implementation sees an extension that it does not understand, it >>> SHOULD ignore that extension.“ >>> Maybe it’s just me because I may have missed some context but does „ignore“ >>> mean here that it should log it or not? >> >> "It" (the precertificate or certificate) must have already been logged, >> because the corresponding SCT (that contains a potentially unrecognized >> extension) couldn't otherwise exist. > > Could be good to clarify in the text. I think other sections of the document already make it clear that a certificate or precertificate must be submitted to (and accepted by) a log before an SCT will be produced. Section 3 says: "If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT)" Section 4 says: "When it receives and accepts a valid submission, the log MUST return an SCT that corresponds to the submitted certificate or precertificate." I think reiterating this point again would be both unnecessary and out of scope for section 4.8, the purpose of which is to define the structure of an SCT. >>> 5) sec 5: „MAY retry the same >>> request without modification at a later date.“ >>> Would it be possible to provide a recommendation how long the client should >>> wait? >> >> The very next sentence in section 5 already specifies a mechanism for >> doing just that: >> 'Note that as per >> [RFC7231], in the case of a 503 response the log MAY include a >> "Retry-After:" header in order to request a minimum time for the >> client to wait before retrying the request.’ > > I meant, would it make sense to actually provide a default value or something > for this waiting time? We could, but it would be fairly arbitrary. So why bother? Some transient failures may be very short-lived, but others may last for hours. Only the log operator can possibly know how long a client should wait before retrying a request would be expected to succeed. >>> 6) sec 5.6: „Logs MAY restrict the number of entries that can be >>> retrieved per >>> "get-entries" request.“ >>> Should this be added to sec 4.1? >> >> I don't think that's a good idea. I can imagine that operational issues >> might cause a log operator to want to vary this restriction at any time. >> >> Clients should always be prepared to receive get-entries responses that >> contain fewer entries than they requested. >> >> See also https://trac.ietf.org/trac/trans/ticket/95 >> >>> 7) sec 10.3: Couldn’t you use the TLS SignatureScheme Registry directly >>> (instead of forming an own registry)? >> >> It makes sense to synchronize the signature algorithm values we use with >> the TLS SignatureAlgorithm registry, because our data structures are >> defined according to the conventions laid out in the TLS RFC. >> >> However, I don't think it's a good idea to use the TLS >> SignatureAlgorithm registry directly. In 6962-bis, we've taken steps to >> make log artifacts smaller (compared to RFC6962); related to that, we've >> removed the option of logs being permitted to use RSA keys/signatures. >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 >> permits RSA, and several other signature algorithms that we don't wish >> to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for >> Private Use"). >> >>> 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more >>> appropriate >>> for the VersionedTransTypes registry? >> >> In 6962-bis section 10.4.1, we ask the appointed Expert to "review the >> public specification to ensure that it is detailed enough to ensure >> implementation interoperability". >> >> AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, whereas >> "Specification Required" does. So I think we should leave it as >> "Specification Required”. > > RFC Required implies that the document got some reviews based on the > respective process. > > However, I guess I actually wanted to propose IETF Review (and used the wrong > term). That would imply that it had to go through the IETF process with > respective review (and therefore usually it is expected that no expert review > is needed in addition). Anyway this was mainly a comment to double-check this > decision. I personally don't have a preference, but I'll start another list thread to discuss this proposal. >>> 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 >>> recommend to >>> always (clearly) name the registry. >> >> Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (see >> https://github.com/google/certificate-transparency-rfcs/pull/309), we've >> already clarified that the Log ID Registry is indeed First Come First >> Served. >> >>> And finally one higher level question mainly out of curiosity: was it >>> considered to e.g. use json for all data structures? Is there a performance >>> reason to not do that or wasn’t that even discussed? >> >> Please don't restart the format wars. ;-) > > Didn’t know that… > >> >> We must use ASN.1 for all data structures, because X.509 certificates >> are involved. But we must use "TLS encoding" for all data structures, >> because TLS is involved. But we must use JSON for all data structures, >> because JSON is more API-friendly. >> >> It was impossible to please everyone. We had to choose something, so we >> chose TLS encoding for the data structures, and JSON for the APIs. >> >> As I mentioned earlier, one goal of 6962-bis is to make log artifacts >> smaller. TLS encoding is more suited to this than JSON. > > Okay thanks for the background info. As long as this was discussed that's > fine! -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
