Thanks for your additional reply and work!
> On 30. Jul 2021, at 06:02, Paul Wouters <[email protected]> wrote: > > > Hi Mirja, > > We believe we have addressed all your comments in previous versions of > the draft. Please let us know if you feel any of your COMMENTs are not > addressed. > > Paul > > ---------- Forwarded message ---------- > Date: Wed, 16 Oct 2019 09:36:58 > From: Rob Stradling <[email protected]> > Cc: The IESG <[email protected]>, > "[email protected]" > <[email protected]>, Paul Wouters <[email protected]>, > "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > To: Mirja Kuehlewind <[email protected]> > Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: > (with > DISCUSS and COMMENT) > > 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
