On 27/12/2018 17:03, Ryan Sleevi wrote:
> On Thu, Dec 27, 2018 at 11:43 AM Rob Stradling 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)
It doesn't prohibit v1/v2 certificates that are accepted trust anchors,
since that text in the PR only applies to "the zero or more intermediate
CA certificates in the chain".
Intermediate CA certificates that conform to RFC5280 cannot be v1 or v2.
However, I suppose X.509v1 and X.509v2 certs currently (in
draft-ietf-trans-rfc6962-bis-30) fall under "Logs MAY accept
certificates and precertificates that...are otherwise not fully valid
according to RFC 5280 verification rules". Hmmm...
Shall I change that part of the PR to read as follows?
"* Each of the zero or more intermediate CA certificates in the chain
MUST have one or more of the following features:
* The Version field has the value v1(0) or v2(1).
* The Basic Constraints extension with the cA boolean asserted.
* The Key Usage extension with the keyCertSign bit asserted."
Is there even such a thing as a v1 or v2 intermediate CA certificate in
any technical standard or any known implementation?
> 2) This would prohibit RFC 3820 Proxy Certificates
Sorry, I've never read this one. Advice welcome.
> 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?
It's the camera. I think this WG reached consensus on that long ago.
Right?
> 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
"and to set clear expectations for what monitors would find in the log"
originated in this PR from Eran back in March:
https://github.com/google/certificate-transparency-rfcs/pull/293/files
Perhaps we should delete this clause?
> (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.
How about I change "...attributable to an accepted trust anchor..." to
"attributable to a once or currently accepted trust anchor..." ?
> The primary reason for any of
> this largely is about preventing Log DoS (whether from spam or
> content/profile, collectively, "invalid submissions").
I agree.
> Basic constraints
> and usage are really just variants of DoS prevention, right?
Yes.
--
Rob Stradling
Senior Research & Development Scientist
Email: [email protected]
Bradford, UK
Office: +441274024707
Sectigo Limited
This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
