[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

[Kirk Hall]

Yes, good faith is always intended, and I believe you also are also acting in good faith.  I already responded to Jacob, but I can tell you that the normal rules of statutory construction are, any reference in a law (e.g., requirements) to an external rule or standard controlled by others does *not* normally change automatically if the external rule or standard changes.  That’s why state legislatures typically have to pass a bill changing their own state tax laws if they were linked to or synched with federal tax laws if the federal tax laws are changed by Congress.   The state must “reconnect” to the new version via new legislation that explicitly does so.  Otherwise it’s a delegation of its own authority to others, which is not allowed.

Just reporting the facts.

From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, October 22, 2019 5:54 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

While I want to assume good faith here, and assume it was based on unfamiliarity with the IETF process, I'm deeply concerned about the nature of the question. The Baseline Requirements are fundamentally a profile based on a number of RFCs - RFC 3647 and RFC 5280, most notably. The ability to accomplish anything, within this Forum, requires deep understanding of the technical basis for how CAs are operated and how the Baseline Requirements are defined. My hope is that your colleagues at Entrust Datacard will be able to provide sufficient explanation here to explain why this assertion doesn't make sense, and why the questions are similarly concerning.

Section 1.6.3 of the Baseline Requirements details the various external documents like an RFC that the BRs are built-upon, as well as a host of external documents. This is essential knowledge for any publicly trusted CA, and certainly essential for the requirements in the Baseline Requirements.

The question of the IETF process is, understandably, more subtle, but similarly essential to obtaining the correct and desired result from a CA that may be or is trusted. I don't want to discourage questions, as those are very welcome, but the categorical statement associated with the questions is part of the concern.

The IETF process can be further read and understood at https://www.ietf.org/standards/process/ , but the abridged version is that an RFC is a stable identifier. It is the versioned document itself. If it is subsequently replaced (e.g. v2), then a new RFC number is assigned. If the RFC is defined extensibly, it may be updated - however, those updates appear in a new RFC, and they reference the existing RFC.

This model is what allows, for example, CAs to issue certificates for RSA or ECC keys, which are not directly addressed within RFC 5280. It is similarly the model that allows CAs to issue certificates with organizationIdentifier fields, which are not directly addressed within RFC 5280.

I hope you can see this concern is unfounded, and already extensively part of the BRs, as it is the very foundation of the Baseline Requirements themselves.

On Tue, Oct 22, 2019 at 8:23 PM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
It’s problematic for the BRs to refer to an external document like an RFC.  Which version of the RFC – the one in effect when the ballot is adopted (that is usually the rule with statutory construction)?  Or would we be saying the BRs will automatically follow any future changes to the RFC – which we may not like?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/52ecaa9f/attachment.html>