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

[Kirk Hall]

Wow – you used the phrase “interesting trivia”.  You always surprise me Ryan – that’s a new one -  but I’m sure you were posting in good faith.

Suppose RFC 8305 says “All certificates must be Red”

The Forum then says “What a great idea!  Let’s amend the BRs to say “All CAs must follow RFC 8305”.

Then six months later, the small group of authors of RFC 8305 amend it to say “No, all certificates must be Blue.”  (Remember, RFCs are sometimes dominated by a small group who are trying to promote their own ideas or their companies’ commercial plans through an RFC.  That’s why so many RFCs never become standards.)

Members of the Forum (browsers and CAs together) say “Wait, that’s not what we agreed to!  We don’t want that!”  And so the changes to RFC 8305 do not automatically become part of the BRs.

So that’s why changes to RFCs cannot automatically become changes to the BRs – it’s very basic.  The Forum Members need to examine any RFC changes, and decide if they are still consistent with the Forum’s original objectives, or not.

If we don’t do that, we are essentially delegating our ability to make our own decisions in the Forum to others, who may or may not have the best interests of the internet in mind.

So changes to the RFCs must be explicitly adopted by the Forum in new ballots in order to be effective.  And by the way – that’s how the rest of the physical world also works.  If the Government of Utopia says “We hereby adopt the electrical standards of the World Electric Board  to apply to Utopia”, and the World Electric Board later changes its standards to v1.1 where polarity of wires is reversed, ordinarily the Government of Utopia must then take action to update its standards to accept (or reject) v1.1.  If you don’t believe me, go check with Google’s legal counsel and you will find out I am right.

Note: This is how the Forum has treated amendments to WebTrust and ETSI standards in the past – even if WebTrust or ETSI decide to change their own standards, those changes do not automatically become binding on Forum members until they are adopted by the Forum in a new ballot.  The same is true for changes to RFCs made by others.

From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, October 22, 2019 6:46 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



On Tue, Oct 22, 2019 at 9:15 PM Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
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.

I'm not sure the relevance of this information to the Forum or its activities, or to the Ballot in question. While it is interesting trivia, it is neither useful nor relevant to the activities here. At best, we're developing a technical document that may inform auditing criteria. Technical documents regularly incorporate, by reference, other technical documents. The concern you raised, of documents changing, is not relevant to the proposal you were discussing; however, technical documents changing to the latest version is not by any means untowards. For example, note Section 2.2 of the BRs, which require CAs state and describe an adherence to the latest possible document, which precludes any reconciliation or syncing.

As this seems further off-topic, it sounds like we're in agreement that your concerns with referencing RFC 6962 are entirely unfounded; the BRs reference external documents extensively, and RFC numbers are themselves version numbers.

Were there other concerns unexpressed and unaddressed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/477887d3/attachment.html>