[Trans] Mirja Kühlewind's Discuss on draft-ietf-trans-rfc6962-bis-31: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


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.


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

 2) Please expand STH on first occurrence (in sec 4.1)

 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?

 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?

 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?

 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?

 7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly
 (instead of forming an own registry)?

 8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate
 for the VersionedTransTypes registry?

 9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to
 always (clearly) name the registry.

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?