Andrew, Thanks for taking the time to review the document and for the nice organization of your comments.
A. Logs do not check for syntactic misissuance Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check, or ought to check, submitted certificates for syntactic misissuance. Page 20 says that syntactic misissuance will be detected "only if" a (pre-)certificate is submitted to a log that performs syntactic checks. There was no intent to suggest that logs do or ought to perform syntax checks. Sorry for any confusion in that regard. I did find several places where uppercase reserved words appear, which is inappropriate for an informational RFC. I will change all of these to lowercase. Also, note that 6962-bis says: “Logs SHOULD accept certificates and precertificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain.” This text suggests that some logs might choose to verify certificate syntax as part of path validation, although none need to do so. The text goes on to note that a log may choose to accept certs that violate some 5280 rules, which also suggests to me that syntax checking is not outlawed by 6269-bis. It acknowledges that this leniency is needed to accept “quirks of CA certificate-issuing software.” This is not an intended function of logs, and not a single one of the 58 logs currently in operation performs syntactic misissuance checks. Furthermore, having logs perform this function would violate separation of concerns. Instead, monitors perform syntactic misissuance checks. crt.sh, for instance, runs all certificates through several certificate linters. The document examines possible ways that one might detect syntax problems and how elements of CT might facilitate remediation of detected problems. Logs, if they chose to perform such checks, could help in this respect and that’s why they are discussed, irrespective of how logs currently operate. Also, I don’t see where 6962-bis states that a monitor performs syntax checks. For example, the 6962-bis text for the description of Monitor operation still says “Monitors watch logs to check that they behave correctly, for certificates of interest, or both.” (The “or both” makes no sense here, as I noted several times in 2017, but …) Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate. I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again. CAs must perform syntactic checks on the TBSCertificate prior to signing anything. In principle yes, but in practice, … “quirks of CA certificate-issuing software” Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans and have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely. I believe that the two I-Ds in question were generated because of the text that I was writing here, not the other way around. The text in 4.1.1.1 says that a log could optionally check for syntax problems; it does not say that they MUST/SHOULD do so. I'll change the text in 4.1.1.1 to note, parenthetically, that syntax checks by a log are optional. B. Conflation of log misbehavior and CA misbehavior Page 4 says that if a bogus SCT is discovered, it would trigger a revocation request. Page 26 says that browsers need to "reject certificates that contain SCTs from conspiring logs." Page 4 says that discovery of a bogus SCT would "presumably, trigger" a revocation request. Page 26 does not require a browser to reject a certificate that does not contain an SCT. (As noted above, this document is not intended to establish requirements for any element of the CT system.) 5.4 describes issues that might arise IF such behavior were adopted. Page 3 says "if an RP verified that a certificate that claims to have been logged has a valid log entry, the RP would have a higher degree of confidence that the certificate is genuine." But behavior of a log says nothing about whether a certificate was properly issued. A properly-issued certificate might be logged to a a misbehaving log, and a misissued certificate might be logged to a well-behaved log. Therefore, browsers should not consider a certificate more likely to be genuine just because it's logged, and if a certificate contains an embedded SCT from a log that's known to be bad, the browser should reject only that SCT, and still check SCTs from other logs. And there is no need to revoke a properly-issued certificate just because it's submitted to a log that misbehaves. I agree that a browser placing greater trust in a certificate because it has been logged is not fool-proof. However, it represents an important initial check. I believe Richard Barnes made some good arguments on the list last year about the utility of logging and the complexity and potential privacy issues that arise if browsers engage in auditing. So, yes, I believe that receipt of a certificate containing an SCT probably will inspire greater confidence. I will revise the text to insert the term "probably". Browser interactions with an audit system are not yet standardized and present some privacy concerns, so one ought not assume that the more extensive checks you note will be widely deployed. Section 5.3 says that "evidence of a bogus or erroneous certificate" can be "in the form of a log entry and/or SCT." An SCT is irrelevant for this, as it attests only to log behavior. An SCT can be used to retrieve a log entry, so it seems reasonable to include it here. I’ll revise the text to say that a log entry or SCT is supporting evidence. C. Response to log misbehavior On pages 4, 9, and 13, the draft says that monitors should not "trust" or "rely upon" misbehaving logs. But monitors don't trust or distrust logs - they just view logs as a source of certificates. Browsers, on the other hand, do trust and distrust logs. For example, after two logs (WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but Cert Spotter and crt.sh continued monitoring them until they shut down. The document should be updated to remove mention of monitors trusting or relying upon logs, and to make clear that the primary response to a misbehaving log is for browsers to distrust it. A monitor selects a set of logs that it will use to check for mis-issued certificates. By so doing it is implicitly trusting (relying on) them. If they are detected to misbehave, Monitors will, presumably, stop relying on them, as you indicated in your example. D. Signature/chain mutation attack There's another way a log can misbehave which ought to be mentioned in section 3.1.1.2. A misbehaving log that conspires with a CA could log a misissued certificate, but mutate the certificate's signature or chain such that the certificate is no longer cryptographically attributable to the CA. The CA could then plausibly deny that it issued the certificate. Since the signature and chain are not part of the Merkle Tree, the SCT will be accepted by browsers and be auditable, despite the log entry being mutated and useless for responding to the misissuance. Monitors should be sure to validate the signature and chain of logged certificates so that this misbehavior can be detected. I don’t think I understand the attack. Where is the mutated certificate signature? If you can provide a clear, detailed description of the attack I could include it in the revised text. E. Chrome is requiring SCTs now As David A. Cooper pointed out, Chrome is now requiring new certificates to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates. As I noted in my reply to David, Chrome is just one browser. The WG has been informed, in the past, that the Chrome developers reserve to right to do whatever they feel is best for that product, irrespective of what the IETF describes in an RFC. So, for now, I don’t think, the sections in question require changes. F. Organization The organization of the draft seems sub-optimal. At a high level, the document is broken up into semantic and syntactic misissuance, and then into malicious vs non-malicious CA. Within these categories, the document discusses the implications when the certificate is logged, not logged, or when the log is misbehaving. Very often, these implications are the same regardless of the type of misissuance or the culpability of the CA. As a result, there is a lot of duplication, often with minor differences in wording, which makes the document harder to understand. I think the structure of section 5, which discusses issues as standalone concepts, is a better model. Alternatively, the duplication could be removed from sections 3 and 4 and replaced by references to prior sub-sections. I agree that there is some duplication, but I prefer the taxonomic approach and I’ve used that in other threat/attack documents, most recently RFC 7132. It’s rather late in this process to suggest a massive revision of the document. G. Minor comments Page 3 says "'bad-CA-lists' a CA as noted above". "Bad-CA-list" hasn't been defined and doesn't appear to be noted above. Fair point- I’ll try to provide an in-context definition. BTW, the cited text appears on page 4, not 3. Page 3 talks about "validat[ing]" an SCT, which is ambiguous, as it could refer to checking the SCT's signature, or auditing the SCT for inclusion. I suggest replacing "validates" with "audits" and replacing "is invalid" (in the same sentence) with "fails auditing." Section 8.1.3 of 6962-b defines SCT validation as checking the SCT signature, period. I’ll cite that section in the text. BTW, the cited text appears on page 4, not 3. Page 4 says that "a CA benefits from CT when it detects a (mis-issued) certificate that represents the same Subject name as a legitimate certificate issued by the CA." How is a CA supposed to know if the certificate is misissued or not? I’ll reword the text to indicate that I was envisioning a CA acting as a Monitor for its clients in this case. BTW, the cited text appears on page 5, not 4. Page 10 says that a monitor/auditor will detect a misbehaving log when it "sees the bogus certificate." It also needs to see the SCT. If the pre-certificate was logged, the certificate contains the SCT. But, to be general, I’ll add a parenthetical reference to the SCT. BTW, the quoted text appears on page 11, not 10. Section 3.1.2.1 talks about a Subject being able to detect the lack of an SCT in a certificate that it is issued. Since this is part of the section on "Semantic misissuance," which is defined in the Introduction as a certificate issued to someone who isn't the Subject, it's unclear to me what the point of this sub-section is. A Subject, by definition, would never be issued a semantically misissued certificate. Fair point- I’ll move this text to Section 4.1.2 Section 3.3.1 ends with "If the bogus certificate is detected and logged, browsers that require an SCT will reject the bogus certificate." Wouldn't the logging of a certificate cause an SCT to be issued, and thus allow it to be *accepted* by browsers that require an SCT? Fair point- I’ll reword the text to note that if the certificate is logged, it is subject to detection as bogus. Since the CA is presumed to be malicious, it may delay revocation or try to suppress revocation status distribution (as per 3.5). Inn this case even browsers that require an SCT are still vulnerable. The last paragraph of section 3.5 talks about the attack in 3.4 and should be moved. The sentence that refers to “CA certificate 2” does belong with the discussion in 3.4, so I will move it to the end of that section. The rest of the text talks about ways that one might counter attacks based on manipulating distribution of revocation status, and thus belongs at the end of 3.5. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
