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?
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
