On 2 October 2014 17:13, Stephen Kent <[email protected]> wrote: > Rob, >> >> On 01/10/14 16:05, Stephen Kent wrote: >> <snip> >>> >>> Rick, >> >> <snip> >>> >>> Still, your point is a good one. We could push the syntax checking back >>> to Monitors, but then we loose the ability to provide immediate feedback >>> to CAs that are issuing syntactically malformed certs. I'll have to think >>> more about this issue. >> >> >> Stephen, >> The "ability to provide immediate feedback to CAs that are issuing >> syntactically malformed certs" sounds like a nice idea, but surely this >> could be implemented as a stand-alone application or web service? >> Why would you want it to be an intrinsic part of CT? > > The motivation for making it part of CT arose when Ben explained that his > definition of mis-issuance included syntactic constraints from the CABF > context. The notion that immediate feedback is > desirable is consistent with the overall CT goal of forcing CAs to do > something by threatening > that there certs will be rejected by browsers, only translated to logs :-). > > Still, your argument that logs ought not reject certs that fail to meet > syntactic criteria, > so that all TLS clients can benefit from detection of mis-issued certs > detection via > examination of logs, is compelling. > > I have a suggested solution: > > - require a CA submitting a pre-cert to assert one of the following: > 1. no assertion is made wrt syntactic conformance to CABF guudelines > 2. the cert conforms to DV Guidelines <insert guideline version> > 3. the cert conforms to EV guidelines <insert guideline version> > > - require a log to include the CA assertion in its SCT, along with one > of the following: > 1. this log does not check cert syntax > 2. this log cannot check the specified CABF Guidelne version > asserted by the CA > 3. this log checked the cert against the CA's assertion and it > passed > 4. this log checked the cert against the CA's assertion and it > failed
Presumably this would apply to certs as well as precerts, which is the other reason rejecting isn't particularly helpful (certs are already issued by the time they're logged!). > This would seem to address the concern that rejecting (not logging) a > submitted cert is > worse than logging a bad cert. It also addresses the concern that Rick > mentioned, i.e., > a mismatch between what Guideline version a CA is using vs. what a log can > verify. It > does not require that every log perform ANY syntax checking, and it lets > Monitors and > clients know whether a log has elected to no perform such checks. It also > tells a Monitor > which set of cert syntax rules the CA says it is enforcing, so that the > Monitor can perform > the checks. If the log doesn't perform checks, or is unable to check a > specific version of > the syntax checks, the Monitor can step in do so. The Monitor also can > double check the > log, to detect logs that are not doing the checks properly, e.g., because of > errors, compromise, > or conspiracy. This provides Monitors and clients with additional info when > choosing which logs > to use. > > Would this mechanism address your concerns? > > Steve > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
