Subject: [sidr] Fwd: [Errata Rejected] RFC6487 (3168)

From: Stewart Bryant <[email-masked]>
Date: Mon, 06 May 2013 13:30:32 +0100

Whilst this change was supported by one author and one of the chairs,
it is a technical change and thus outside the scope of change
permitted in an errata.

The correct approach is for a member of the WG to produce a
short update draft and test that this has WG and IETF consensus.

Please can the chairs drive this process.

- Stewart

-------- Original Message --------
Subject: 	[Errata Rejected] RFC6487 (3168)
Date: 	Mon, 6 May 2013 05:24:39 -0700
From: 	RFC Errata System <[email-masked]>
To: 	<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
CC: 	<[email-masked]>, <[email-masked]>, <[email-masked]>

The following errata report has been rejected for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3168

--------------------------------------
Status: Rejected
Type: Technical

Reported by: David Mandelberg <[email-masked]>
Date Reported: 2012-03-26
Rejected by: Stewart Bryant (IESG)

Section: 4.8

Original Text
-------------
    or non-critical.  A certificate-using system MUST reject the

    certificate if it encounters a critical extension it does not

    recognize; however, a non-critical extension MAY be ignored if it is

    not recognized [RFC5280].

Corrected Text
--------------
    or non-critical.  A certificate-using system MUST reject the

    certificate if it encounters an extension not explicitly mentioned

    in this document.  This is in contrast to RFC 5280 which allows

    non-critical extensions to be ignored.

Notes
-----
Other sections of the same document contradict the original section 4.8:

Section 1:

    Any extensions not explicitly mentioned MUST be absent.  The same

    applies to the CRLs used in the RPKI, that are also profiled in this

    document.

Section 8:

    Certificate Extensions:

          This profile does not permit the use of any other critical or

          non-critical extensions.
  --VERIFIER NOTES--
    This is a technical change to the RFC and needs to be addressed though the IETF consensus process and rather than via the errata process.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

.

---

From: Andrew Chi <[email-masked]>
Date: Mon, 06 May 2013 11:02:59 -0400

Is this really a technical change?  The document has two places that 
state X, and one place (citing 5280) that states Y.  This erratum 
replaces the Y statement with X.  All implementers have already 
implemented X since it's the stricter form of Y.

X = no other extensions are allowed
Y = non-critical extensions MAY be ignored

If this truly is a technical change, then we should have an update doc. 
  But I'm just trying to minimize needless words.

Andrew

On 5/6/2013 8:30 AM, Stewart Bryant wrote:
> Reported by: David Mandelberg<[email-masked]>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Danny McPherson <[email-masked]>
Date: Sat, 11 May 2013 22:33:59 -0400

On May 6, 2013, at 11:02 AM, Andrew Chi wrote:

> Is this really a technical change?  The document has two places that state X, and one place (citing 5280) that states Y.  This erratum replaces the Y statement with X.  All implementers have already implemented X since it's the stricter form of Y.
> 
> If this truly is a technical change, then we should have an update doc.  But I'm just trying to minimize needless words.

Andrew, 
Would an implementer need to know the difference when writing code based on the current standards track RFC, or would they need to read the erratum?

-danny

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 13 May 2013 15:48:30 +0100

> Would an implementer need to know the difference when writing code based on the current standards track RFC, or would they need to read the erratum?
That is indeed the key question. Errata (only) document obvious mistakes 
in the original text, and are rarely read by implementers since few know 
of there existence.  By contrast an update will be flagged to them in 
the metadata. In this case my assessment was that the matter was 
technical and outside the scope of an errata a view I confirmed with 
others on the IESG.

The update does not need to be a big document, but it will (if 
published) have WG and IETF consensus for the change it makes.

- Stewart