[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Oct 24 11:20:56 MST 2019
On 2019-10-24 5:47 μ.μ., Tim Hollebeek via Servercert-wg wrote:
>
> Despite being capitalized, Precertificate is not a defined term in the
> BRs; while we are in here, we should probably fix that.
>
Jeremy's proposal was in the right direction adding these terms to the
definitions section (1.6.1).
https://cabforum.org/pipermail/servercert-wg/2019-October/001289.html
I am still having hard time reading and understanding:
"If the OCSP responder receives an OCSP request but has no record of
ever having issued any certificate with the certificate serial number in
that request, using any current or previous issuing key for the CA
subject, then the responder SHOULD NOT respond with a "good" status.
OCSP responders for CAs that are not Technically Constrained in line
with Section 7.1.5 MUST NOT respond with a "good" status for such
certificates. The CA SHOULD monitor the responder for such requests as
part of its security response procedures."
Dimitris
> I also think that being able to respond “GOOD” in the case where there
> is neither a Precertificate nor a Certificate would be a rather
> unfortunate regression.
>
> -Tim
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
> Of *Wayne Thayer via Servercert-wg
> *Sent:* Tuesday, October 22, 2019 7:45 PM
> *To:* Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates
>
> I'm posting v2 of this ballot because without it the discussion period
> will expire and the ballot will fail. V2 adds language required to
> prevent conflicts with ballot SC24, but does not otherwise change the
> proposal.
>
> It's not clear to me how to proceed with this. It seems that the
> endorsers are happy with the current ballot, but others want to limit
> the change to section 4.9.10. So far, no one has proposed specific
> language that both accounts for all of the nuances of this issue and
> is considered to be easily understood. Unless specific alternative
> proposals are made, I'm inclined to proceed to a vote on the current
> proposal.
>
> ==========================
>
> Ballot SC23 v2: Precertificates
>
> Purpose of Ballot:
>
> This ballot intends to clarify requirements placed on precertificates
> in BR section 7.1.2.5.
>
> During a lengthy discussion on the mozilla.dev.security.policy forum
> [1], it was discovered that BR section 4.9.10 combined with BR section
> 7.1.2.5 prevents a CA from responding “good” for a precertificate.
> This is a problem because there is no guarantee that a certificate
> corresponding to a precertificate has not been issued, resulting in
> root store policies such as [2] that require CAs to treat the
> existence of a precertificate as a presumption that a corresponding
> certificate has been issued and thus that a valid OCSP response is
> required.
>
> This ballot intends to resolve the problem by reducing the scope of
> section 7.1.2.5. This section was originally [3] intended only to
> address duplicate serial numbers that would violate RFC 5280 section
> 4.1.2.2. In addition, this ballot removes legacy effective dates from
> BR section 4.9.10.
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/NbOmVB77AQAJ
>
> [2]
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
>
> [3] https://cabforum.org/pipermail/public/2014-January/002694.html
>
> The following motion has been proposed by Wayne Thayer of Mozilla and
> endorsed by Jeremy Rowley of DigiCert and Rob Stradling of Sectigo.
>
> -- MOTION BEGINS --
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on
> Version 1.6.6, or based on Version 1.6.6 as modified by ballot SC24:
>
> *REPLACE section 7.1.2.5 of the Baseline Requirements in its entirety
> with:*
>
> 7.1.2.5 Application of RFC 5280
>
> For purposes of clarification, any Precertificate MAY have the same
> serial number as exactly one certificate that is not a Precertificate,
> provided that the two are related as described in RFC 6962 -
> Certificate Transparency. This is a modification of the uniqueness
> requirements of RFC 5280 - Internet X.509 Public Key Infrastructure
> Certificate and Certificate Revocation List (CRL) Profile section
> 4.1.2.2 under these Baseline Requirements.
>
> *REPLACE section 4.9.10 of the Baseline Requirements in its entirety
> with:*
>
> 4.9.10 On-line Revocation Checking Requirements
>
> The CA SHALL support an OCSP capability using the GET method for
> Certificates issued in accordance with these Requirements.
>
> For the status of Subscriber Certificates:
>
> The CA SHALL update information provided via an Online Certificate
> Status Protocol at least every four days. OCSP responses from this
> service MUST have a maximum expiration time of ten days.
>
> For the status of Subordinate CA Certificates:
>
> The CA SHALL update information provided via an Online Certificate
> Status Protocol at least (i) every twelve months and (ii) within 24
> hours after revoking a Subordinate CA Certificate.
>
> If the OCSP responder receives an OCSP request but has no record of
> ever having issued any certificate with the certificate serial number
> in that request, using any current or previous issuing key for the CA
> subject, then the responder SHOULD NOT respond with a "good" status.
> OCSP responders for CAs that are not Technically Constrained in line
> with Section 7.1.5 MUST NOT respond with a "good" status for such
> certificates. The CA SHOULD monitor the responder for such requests as
> part of its security response procedures.
>
> -- MOTION ENDS --
>
> This ballot proposes a Final Maintenance Guideline.
>
> *** WARNING ***: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE
> OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
> A comparison of the changes can be found at:
> https://github.com/wthayer/documents/commit/f0b7c0a27fe51e73d5ed5d8d453024c51713ed70
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 3-October 2019 18:00 UTC
>
> End Time: No earlier than 30-October 2019 00:00 UTC
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
> On Mon, Oct 21, 2019 at 2:59 PM Ryan Sleevi via Servercert-wg
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>
> Kirk,
>
> I appreciate the desire to provide language, but I think we should
> be careful not to repeat the same mistakes as Ballot 134.
>
> For example, what does it mean to "provide OCSP responses for
> pre-certificates". If you use a Precert Signing CA, what is
> literally in that text makes no sense, and will inevitably lead to
> the "wrong result". You wouldn't have the Precert Signing CA
> define an OCSP responder, nor would the OCSP response be issued
> from that CA, but would be from the "Issuer" that would be in the
> Precertificate associated with the Issuer of the Precert Signing CA.
>
> This is why it's important not to try for "quick" solutions, but
> to go for technical precision.
>
> On Mon, Oct 21, 2019 at 5:53 PM Kirk Hall via Servercert-wg
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> wrote:
>
> I agree with Dimitris – the language is too complex, and who
> knows if there will be any unintended consequences.
>
> I was told a main reason for the ballot is because Rob
> Stradling thinks BR 4.9.10 forbids CAs from doing providing
> OCSP responses for pre-certificates.
>
> @Rob – if that’s true, why don’t we just amend BR 4.9.10 to
> add this:
>
> “CAs MAY provide OCSP responses for pre-certificates” or maybe
>
> “CAs SHALL provide OCSP responses for pre-certificates”
>
> That’s pretty clear and easy to implement. Of course, we may
> want to add something about what the correct response should
> be if:
>
> * Pre-cert was CT logged, but the production cert has not
> yet been issued
> * Related production cert has been issued and is not revoked
> * Related production cert has been revoked or expired
> * Related production cert is unknown.
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org
> <mailto:servercert-wg-bounces at cabforum.org>> *On Behalf Of
> *Ryan Sleevi via Servercert-wg
> *Sent:* Monday, October 21, 2019 5:53 AM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Ballot SC23:
> Precertificates
>
> On Mon, Oct 21, 2019 at 3:23 AM Dimitris Zacharopoulos
> (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
> On 2019-10-18 4:51 μ.μ., Ryan Sleevi wrote:
>
> On Fri, Oct 18, 2019 at 3:10 AM Dimitris Zacharopoulos
> (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>> wrote:
>
> I believe this language is very difficult to
> understand, at least for
> me.
>
> Any other context to help understand the difficulty or
> confusion?
>
>
> I had to read it 5 times and was still confused about how
> to implement it. This tells me that the language is
> complicated and needs more work :-) Short sentences in
> "simple" English will get us there.
>
> Perhaps we should break down these sentences
> defining what it means
> for a serial number to be "reserved" or "assigned"
> (we don't need to add
> in section 1.6.1) and then state the requirements.
> I think it would be
> easier to read.
>
> Any suggestions for how to accomplish this?
>
>
> I will try to find some time this week to propose a little
> simpler text that maintains all the requirements of your text.
>
> That's what the text currently does, so I'm not sure
> if I'm understanding the concern correctly. Is it to
> move from prose, as it's currently written, into
> something like enumerated bullet points? I avoided
> that because a number of CAs shared concerns with
> expressing requirements like this during the F2F
> (during the discussion about the difficulty
> understanding the BRs), and I was trying to respect
> that view. I'm fully supportive of trying to make sure
> requirements are listed directly as that, with the
> exception of the interpretation issues they create
> ("Default-Deny" being expected, "Default-Allow" being
> the interpretation)
>
>
> Bullet points help break down long sentences. They are not
> meant to exhaustively enumerate available options so IMO
> this is not related to the "Default-Deny", "Default-Allow"
> discussion.
>
> Except the proposed text is explicitly intended to
> exhaustively enumerate available options. That this is not
> clear is a sign that we can improve wording, and I'm looking
> forward to better understanding the concern. I'm not sure how
> best to capture a construct that "This must either be X or Y.
> X means this. Y means that." That is, in my view, quite
> possibly the simplest way to break down the requirements, and
> I'm not sure how we could decompose further, short of
>
> "This must be either:
> * X - which means this.
> * Y - which means that.
> "
>
> That's why I asked for your help in formulating something you
> felt would be clearer.
>
> In the past, I have indicated some paragraphs of the BRs
> that are difficult to understand, especially for
> non-native English speakers. Breaking down these
> paragraphs with simple English, listed items, bullets etc,
> might make them easier to understand and implement.
>
> As far as the "Default-Allow", "Default-Deny" discussion,
> as others have already indicated, this is how standards work.
>
> As I've already said, this is not true, and simply repeating
> it doesn't make it any more true. Plenty of standards work
> this way, and explicitly state whether lists are exhaustive or
> not. My only consideration is that if you'd like to propose
> bullets, as I demonstrated above, you propose it in a way that
> you feel is absolutely clear that only X and Y are permitted,
> and nothing else. Prosasically, this is a bit clearer, because
> it's easy to say it MUST be either X or Y.
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/d3fbe5cc/attachment-0001.html>
More information about the Servercert-wg
mailing list