[Servercert-wg] Referencing RFCs

[Tim Hollebeek]

There is, perhaps, a legitimate point to be made about whether approved IETF Errata are normative or not.  We haven’t run into that situation yet, but it may arise in the future.

 

Another point which has been discussed a few times is how to handle RFCs that update an existing RFC (this is true of RFC 5280, for example).  I’ve heard both opinions expressed over the years, but the BRs themselves are silent on the issue.

 

This is worth discussing but not really related to the Precertificates ballot, so I changed the subject.

 

-Tim

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, October 23, 2019 10:10 AM
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 Wed, Oct 23, 2019 at 12:32 AM Kirk Hall <Kirk.Hall at entrustdatacard.com <mailto:Kirk.Hall at entrustdatacard.com> > wrote:

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.)

 

Hi Kirk,

 

I encourage you to visit the link I previously shared, so you can learn more about the IETF process. You can also discuss with your colleagues at Entrust Datacard.

 

The hypothetical process you described is not how the real world works. It's an interesting thought experiment, to be sure, and it's useful to better understand your confusion. However, it's useful to focus on what actually happens, which I tried to clarify for you previously.

 

I've snipped the rest of your message - it's not useful to consider the strawman argument, since it has no basis in fact.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/978ffa8e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/978ffa8e/attachment.p7s>