On 26/12/2018 19:31, Paul Wouters wrote: > On Wed, 26 Dec 2018, Eric Rescorla wrote: > >> > Logs MAY accept certificates and precertificates >> that have expired, >> > are not yet valid, have been revoked, or are >> otherwise not fully >> > valid according to RFC 5280 verification rules in >> order to >> > accommodate quirks of CA certificate-issuing software. >> > >> > >> > Ah, I thought I remembered this text but didn't see it. What >> about chains in which a properly-issued EE cert signs another EE cert? >> >> The logs will only log data signed by certain CAs. >> >> Where do you think it says that? What I see is text about chaining to >> a trust anchor, not about certificates signed directly by specific >> CAs. And in this case, there would be a chain of signatures to a trust >> anchor. > > Ahh I understand our differences now. I was thinking in terms of CA > signed, and not in the proper terms of "anchors to a trust anchor". > > As for path length, the draft states: > > Logs SHOULD limit the length of chain they will accept. The maximum > chain length is one of the log's parameters (see Section 4.1). > > As you poined out, additional text is needed to cover denial of service > possibilities by EE-certs and intermediate CA's signing CA/EE certs > at (and beyond) the root anchor's path length or log max chain. > >> > (A log may decide, for example, to >> > temporarily reject valid submissions to protect >> itself against >> > denial-of-service attacks). >> > >> > So perhaps this corner can be left to local policy of >> the log operator. >> > >> > >> > Unfortunately, no. This is a 2119 MUST and therefore the >> boundaries of the mandate need to be precisely delineated. >> >> The MUST is not violated by _temporarilly_ halting logging as >> the text describes. >> >> >> The relevant MUST is the requirement to *reject* certificates in the >> following paragraph. >> >> Logs MAY accept certificates and precertificates that have expired, >> are not yet valid, have been revoked, or are otherwise not fully >> valid according to RFC 5280 verification rules in order to >> accommodate quirks of CA certificate-issuing software. However, logs >> MUST reject submissions without a valid signature chain to an >> accepted trust anchor. Logs MUST also reject precertificates that do >> not conform to the requirements in Section 3.2. >> >> And what must clearly be delineated is the boundaries of that MUST. > > Right, so likely a sentence should be added like: > > Intermediate CAs used for validation to an accepted trust anchor > MUST pass all RFC 5280 verification rules, such as the Basic > Constraint path length and CA flags. Certificates failing these > constraints could be valid to be accepted to the log themselves > (eg as a valid intermediate CA or EE-cert), but signatures > created by these certificates MUST NOT be accepted as a trusted > chain to the log's trust anchors and therefor MUST NOT be > logged. This prevents bogus certificates from spamming the log. > > Although possibly, instead of MUST NOT we could say "MAY temporarilly > reject" like the other DoS case. <snip>
Proposed text: https://github.com/google/certificate-transparency-rfcs/pull/305 This PR takes an axe to the "Accepting Submissions" section, splitting it into two subsections in order to (I think) more clearly specify (1) what are the minimum rules for acceptable submissions and (2) what's left to the log's discretion. I've added text to the minimum rules subsection regarding checking the Basic Constraints and Key Usage extensions. I'd like to hear your thoughts about the general approach of this PR as well as its detail. Thanks! -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
