On Thu, Dec 27, 2018 at 9:09 AM Ryan Sleevi <[email protected]> wrote:
> > > On Thu, Dec 27, 2018 at 11:43 AM Rob Stradling <[email protected]> wrote: > >> >> 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! >> > > Just to highlight and ensure it's intentional: > 1) This would prohibit X.509v1 and X.509v2 (by virtue of requiring at > least one extension) > 2) This would prohibit RFC 3820 Proxy Certificates > > I totally accept that this is a wobbly gray area - some arguing only > properly DER-encoded, fully-profile-conforming certificates should be > accepted (which makes writing MUSTs easier and, by proxy, is assumed to > clean up the ecosystem), others wanting to capture the world-as-it-is, not > the world-as-it-should-be. Is CT a means of achieving the PKIX Protocol > Police, or is it the camera that merely records all, without passing > judgement or opinion? > > That said, I'm not sure the motivations for why these requirements are > there are supported by the text. That is, expectations about what a monitor > will find in the log aren't necessarily set (because the trust anchors may > change over the lifetime of the log), and likewise, the attribution issue > is problematic because, again, the trust anchors accepted by the log may > chance over time. The primary reason for any of this largely is about > preventing Log DoS (whether from spam or content/profile, collectively, > "invalid submissions"). Basic constraints and usage are really just > variants of DoS prevention, right? > What's fraught about this from my perspective is that the current text requires that the server *reject* certificates which don't conform to certain rules, apparently in the name of DoS protection. As a result: - From a formal perspective, the set of certificates which must be rejected needs to be unambiguous - From a technical perspective, we should ensure that it's not trivial to create DoS attacks with certificates that are not required to be rejected (otherwise, the requirement is pointless) -Ekr
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
