Resource Public Key Infrastructure (RPKI) Validation Reconsidered
draft-ietf-sidr-rpki-validation-reconsidered-10

Received changes through RFC Editor sync (changed abstract to 'This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.

The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.

It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.

This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.

Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.')

Received changes through RFC Editor sync (created alias RFC 8360, changed title to 'Resource Public Key Infrastructure (RPKI) Validation Reconsidered', changed abstract to 'This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.', changed pages to 29, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-04-04, changed IESG state to RFC Published)

[Ballot comment]
Thank you for adding text into the document that placates my DISCUSS concerns until others look to implement (and use in anger) this in the wild.

I'm going to leave a part of my original thoughts on this document here for future reflection:
"I get the sense that many of the ramifications for this validation change are yet to be discovered. It worries me that from the shepherd writeup "The existing CA/RP code implementations will support this once published." What experiments have been done to identify any gaps and assumptions?"

And further add that the RPKI is starting to appear, in my eyes, exceptionally fragile when faced with operational realities and also quasi-political issues surrounding trust anchors. Without doubt the underpinnings of routing security and integrity is hard, no surprise that this effort (as one of many that has preceded it) also struggles.

[Ballot comment]
Thanks for resolving my DISCUSS points. I note that there is new explanatory text in the abstract. I suggest similar text be added in an introductory section in the body, since readers are known to sometimes skip the abstract.

I am leaving my other comments below for documentation purposes; I leave it to the authors and shepherd to decide if they are sufficiently addressed.

-------------------

Substantive:

- General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)?

- 4.2.4.4:
-- "Any extension not thus identified MUST NOT appear in
      certificate x." (Repeats multiple times)
That seems to prevent future extensibility. Is that the intent?

-- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
      appear on a CRL issued by the CA represented by certificate x-1"
Is this intended as a requirement to check CRLs? If so, please say that explicitly.


Editorial:

-4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he

- 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or
  both, MUST be present in all RPKI certificates, and if present, MUST
  be marked critical."
"... and if present..." seems redundant, since the previous clause said one MUST be present.

- 4.3.4.3: "... values are NOT supported..."
a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords.

- 4.2.4.4 :
-- "Certificate validation requires verifying that all of the following
  conditions hold, in addition to the certification path validation
  criteria specified in Section 6 of [RFC5280]."

The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc.  are already covered in 5280.

- - "...certificate MUST contain all
      extensions defined in section 4.8 of [RFC6487] that must be
      present."
That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent.

-- "all extensions defined in section 4.8 of
      [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
      present. "
It would be more reader-friendly to mention what extensions are defined in 4.8.9.

-- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
Inconsistent voice.

-- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension."
That seems identical to the first bullet. Should it has said "AS Address Delegation extension"?

[Ballot discuss]
Thank you for considering the stability of the internet's routing system during administrative changes to resources.

One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the plan that a small amount discussion will resolve it.

With the definition of the new validation OID (a idea that I like BTW), at any stage of the certificate issuance can the validation OID be switched? That is a TA has a particular OID and down the tree an issued certificate has a different OID? If that can't happen (and please make that clear in the document) is there plan to migrate the set of all issued certificates to the new OID? and deprecate the old OID?

Logically speaking a trust anchor cannot be thought of as over-claiming. (eg you trust where the self signed cert came from, and its contents) However the new validation  constructs suggest that a TA can over-claim, but it seems like there won't be any warning (as the example in S4.3)  to highlight this possible eventuality when (in the model where all RIRs issue a TA) a resource is transferred from one RIR to another for the clients use. Is that interpretation correct? OR does this new model espouse the belief that all RIRs each issue a TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean that RFC6491 should be updated or made historic?

[Ballot comment]
I get the sense that many of the ramifications for this validation change are yet to be discovered. It worries me that from the shepherd writeup "The existing CA/RP code implementations will support this once published." What experiments have been done to identify any gaps and assumptions?

[Ballot comment]
I am agreeing with Ben's comments and I am generally concerned about lack of certificate extensibility in SIDR. (But I've raised this question when reviewing an earlier SIDR document and the WG didn't change its mind.)

In Section 4.2.4.4:

  3.  The Version, Issuer, and Subject fields of certificate x satisfy
      the constraints established in Section 4.1-4.7 of this
      specification.

There is no section 4.7 in this draft, so I think this should point to the original RFC from which this text was copied.

On page 16:

      *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

This looks like a cut & paste error. I think you meant "Identifier" and "VRS-AS" above?

[Ballot comment]
I am agreeing with Ben's comments and I am generally concerned about lack of certificate extensibility in SIDR. (But I've raised this question when reviewing an earlier SIDR document and the WG didn't change its mind.)

[Ballot comment]
I was confused also if this was an update based on the abstract and shepherd writeup.
As it was decided not to be an update, but to be a new procedure,
suggest tweaking the wording on update/modify, e.g. in the Abstract:
updated procedure/s/procedure.

[Ballot discuss]
This is probably just a matter of me being dense, but I'd like to understand what I am missing:

Is it legal to mix certificate policies in a given cert path? The last paragraph of section 5 implies that you can, but doesn't say so explicitly. If you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4. correctly (and it's likely that I am not), if you run into a cert in the chain that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS value, which would seem to invalidate an certificate further down the chain that _does_ follow this policy?

So, I guess it comes down to the following: If mixed policies are allowed, how does that work? If mixed policies are not allowed, there needs to be text that says that. It's quite possible such text exists (here or elsewhere), and I missed it.

[Ballot comment]
Substantive:

- General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)?

- 4.2.4.4:
-- "Any extension not thus identified MUST NOT appear in
      certificate x." (Repeats multiple times)
That seems to prevent future extensibility. Is that the intent?

-- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
      appear on a CRL issued by the CA represented by certificate x-1"
Is this intended as a requirement to check CRLs? If so, please say that explicitly.


Editorial:

-4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he

- 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or
  both, MUST be present in all RPKI certificates, and if present, MUST
  be marked critical."
"... and if present..." seems redundant, since the previous clause said one MUST be present.

- 4.3.4.3: "... values are NOT supported..."
a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords.

- 4.2.4.4 :
-- "Certificate validation requires verifying that all of the following
  conditions hold, in addition to the certification path validation
  criteria specified in Section 6 of [RFC5280]."

The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc.  are already covered in 5280.

- - "...certificate MUST contain all
      extensions defined in section 4.8 of [RFC6487] that must be
      present."
That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent.

-- "all extensions defined in section 4.8 of
      [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
      present. "
It would be more reader-friendly to mention what extensions are defined in 4.8.9.

-- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
Inconsistent voice.

-- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension."
That seems identical to the first bullet. Should it has said "AS Address Delegation extension"?

[Ballot comment]
This seems like a good change. Not knowing much about the deployment practicalities of BGP, I presume that the set of tools used for validation is sufficiently well-known that CAs will positively know when it is safe to start using the new OIDs?

I found the lack of an introduction section to be odd. Please double-check this document against the I-D Nits document; and, in particular, section 2.2:

I believe "Russ Housley" is misspelled section 8.

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- RPKI - Resource Public Key Infrastructure
- AS - Autonomous System
- ROA - Route Origin Authorization
- CA - Certificate Authority
- CRL - Certificate Revocation List

[Ballot comment]
I found the lack of an introduction section to be odd. Please double-check this document against the I-D Nits document; and, in particular, section 2.2:

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- RPKI - Resource Public Key Infrastructure
- AS - Autonomous System
- ROA - Route Origin Authorization
- CA - Certificate Authority
- CRL - Certificate Revocation List

[Ballot comment]
Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- RPKI - Resource Public Key Infrastructure
- AS - Autonomous System
- ROA - Route Origin Authorization
- CA - Certificate Authority
- CRL - Certificate Revocation List

[Ballot comment]
TECHNICAL
S 4.2.4.4.
Point 5 says:

      Section 4.2.4.2 or Section 4.2.4.3, or both.  The value(s) for
      each of these extensions MUST satisfy the constraints established
      for each extension in the respective sections.  Any extension not
      thus identified MUST NOT appear in certificate x.

Assuming I am reading this correctly, you are saying that no other
extensions at all can be added? That seems contrary to the point of
extensions.

The 4th bullet of point 7 says:

      *  If the IP Address Delegation extension is present in
          certificate x and x=1, set the VRS-IP to the resources found
          in this extension.

I think you mean AS Identifier Delegation

Can you please clarify whether the new syntax defined in 4.2.2.2 and 4.2.2.3
is just the same syntax as in 6487 with a new OID? If not, can you please
describe the differences clearly in this document?


EDITORIAL
It would help if the abstract were more clear about the
problem you were trying to solve.



  8.  If there is any difference in resources in the VRS-IP and the IP
      Address Delegation extension on certificate x, or the VRS-AS and

This might read better if it were "difference in resources between the..."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-rpki-validation-reconsidered-08. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMI Security for PKIX Certificate Policies subregistry of the SMI Security Codes registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a single, new registration is to be made as follows:

Decimal: [ TBD-at-registration ]
Description: id-cp-ipAddr-asNumber-v2
References: [ RFC-to-be, section section 4.2.1 ]

Second, in the SMI Security for PKIX Certificate Extension subregistry of the SMI Security Codes registry also on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

two new registrations are to be made as follows:

Decimal: [ TBD-at-registration ]
Description: id-pe-ipAddrBlocks-v2
References: [ RFC-to-be, section section 4.2.2.1 ]

Decimal: [ TBD-at-registration ]
Description: id-pe-autonomousSysIds-v2
References: [ RFC-to-be, section section 4.2.2.3 ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Third, in the SMI Security for PKIX Module Identifier subregistry of the SMI Security Codes registry also on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

two new registrations are to be made as follows:

Decimal: [ TBD-at-registration ]
Description: id-mod-ip-addr-and-as-ident-v2
References: [ RFC-to-be, section section 4.2.2.7 ]

Decimal: [ TBD-at-registration ]
Description: id-mod-ip-addr-and-as-ident-2v2
References: [ RFC-to-be, section section 4.2.3 ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.
Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-08-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RPKI Validation Reconsidered) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document: - 'RPKI Validation Reconsidered'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies an alternative to the certificate validation
  procedure specified in RFC 6487 that reduces aspects of operational
  fragility in the management of certificates in the RPKI, while
  retaining essential security features.

  The use of this updated procedure is signaled by form of a set of
  alternative Object Identifiers (OIDs) indicating that the alternative
  version of RFC 3779 X.509 Extensions for IP Addresses and AS
  Identifiers, and certificate policy for the Resource Public Key
  Infrastructure (RFC 6484) defined in this document should be used.

  Furthermore this document provides an alternative to ROA (RFC 6482),
  and BGPSec Router Certificate (BGPSec PKI Profiles - publication
  requested) validation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07 ===

Dear authors:

I just finished reading this document.  My review is predicated on the assumption that the intent of the WG is to define an additional validation process, and not amend/change/update/deprecate the existing one…yet, which is why there are not only process changes specified, but also new OIDs.

As written, with Updates and text “to be used in place of” existing specifications, the document achieves the deprecation of the current (old) mechanism: simply because procedurally you are replacing the existing/old text with the new one…and the old one would then not be anymore.  The result then is not coherent with the assumption above, and we will need to rewrite (at least from an intent point of view) the document before progressing.

I think that the easiest way forward would be for this document to say something like: “a new validation mechanism is specified, which uses these new OIDs – the specifications defined in RFCA, RFCB, etc.. apply, except for the following exceptions/changes.”  You should then be able to use most of the substantive text already written.

Please see below for specific comments – including more on why this document should not Update the existing RFCs.

Thanks!

Alvaro.



Major:

M1. Section 4.2.1. (Changes to RFC6484).  This document requests an assignment of a new OID (id-cp-ipAddr-asNumber-v2); both the reference and the policy to be followed are contained here, and not in RFC6484.  IOW, this document shouldn’t Update RFC6484.  Instead, it should request the new OID and simply reference RFC6484 when pointing back to id-cp-ipAddr-asNumber.


M2. Section 4.2.2. (Changes to RFC3779).  Same comment: this document requests the assignment of new OIDs….  Note that if the changes in Section 4.2.2.1. (OID for id-pe-ipAddrBlocks-v2) and Section 4.2.2.3. (OID for id-pe-autonomousSysIds-v2) were to be used in place of the text in RFC3779, then id-pe-ipAddrBlocks and id-pe-autonomousSysIds would end up being deprecated.

M2.1. [minor] The syntax for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 (4.2.2.2 and 4.2.2.4) use the “v1” names.

M2.2. For Sections 4.2.2.5 and 4.2.2.6, I think that what you want to say is (something like): “when the OIDs defined in this document are used, the procedures in RFC3779 are followed, except for the certificate path validation (section 2.3), which is specified in Section 4.2.4.4 of this document, and…”  Again, if the text was to replace what is currently in RFC3779, then those procedures would be deprecated.

M2.3. Same comment for Section 4.2.2.7: amending the specification in RFC3779 results in loosing what is defined there.


M3. Section 4.2.4. (Changes to RFC6487).  Same comments as above: replacing the text (which is what an Update does), would result in the mechanism specified in RFC6487 to be the same as what is specified in this document…which means that the option in the first paragraph (“…MUST issue certificates either as specified in [RFC6487] or with all the amendments specified in the following sections.) would result in the same thing.  As with Section 4.2.2 (above), I think you really should specify what the exceptions are for the extensions defined in this document (and not Update RFC6487).


M4. Section 4.2.4.4. (Amended Resource Certificate Path Validation).

M4.1. [Comment about RFC6487] This document correctly mentions the NotBefore/NotAfter values (which should really be notBefore/notAfter), instead of From/To (in RFC6487).  It seems to me that this is an error in the original text.  Can you please file an Errata against RFC6487?

M4.2. s/Certificate x contains all the extensions that MUST be present/Certificate x contains all the required extensions    The “MUST” is not normative in this context.

M4.3. [minor] s/MUST be satisfy the constraints/MUST satisfy the constraints

M4.4. “If IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.”  What is replaced, the IP Address Delegation extension or the VRS-IP?  If the extension, what does it mean to replace the extension in the certificate?  Note that the text about the AS Identifier Delegation extension is as confusing.

M4.5. “…these values MAY be stored along with the certificate, to facilitate incremental validation…”  This document (and RFC6487) don’t say anything about where to store anything – I don’t think we need that normative “MAY”.  s/MAY/may

M4.6. This text is not needed: “If certificate x uses the original version of [RFC6487], then certificate x MUST be rejected.”

M5. Section 4.2.5. (Changes to RFC6482).  Same comment about not needing an Update/replacing the text/…


M6. Section 5. (Deployment Considerations).  The timeline in Table 1 shouldn’t appear in this specification.  Migration is an operational issue that the community should coordinate separately (and not by specifying a normative timeline in an RFC).  What should be included here are any other migration considerations that should be observed when making the transition – if there’s anything beyond what you already wrote.


M7. Section 6. (Security Considerations). Please point to the security considerations in RFC3779, RFC6482, RFC6484 and RFC6487 as applying here too.  It might be beneficial to include a short discussion of why not immediately rejecting the over-claiming certificates is not a security issue


M8. IANA Considerations.  TBD4/TBD5 are not for IPAddrAndASCertExtn-*, but for the new id-mod-ip-addr-and-as-ident-*.

M9. References
- Please add a reference to RFC2119 and the corresponding boilerplate.
- I don’t think that the reference to RFC6268 needs to me Normative.
- We don’t need references to RFC3849, RFC5398 or RFC5737.
- RFC3280 was Obsoleted by RFC5280



Minor:

P1.  The example in Section 3 is meant to be a continuation from the example in Section 2 (“Certificate 2 from the previous example was re-issued by TA to CA1 and the prefix 198.51.100.0/24 was removed.  However, CA1 failed to re-issue a new Certificate 3 to CA2.”); but Certificate 3 is not the same as the one shown in Section 2.  I think the example still gets the over-claiming point across, but it is “wrong” in that both Certificate 2 and Certificate 3 (not just Certificate 2) would have to change for the problem to happen.

P2, Also in the example in Section 3.  It might be beneficial for the reader if the EE certificate was also marked as invalid; the text says so, but the list of certificates doesn’t.

P3. In several places “[this document]” is used – if the intent is to refer to a specific Section, please indicate which.  If not, then you should get rid of the brackets ([]).

P4. In 4.3: “ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate, as required by RFC 6482.”  The VRS is introduced in this document, not RFC6482.



Nits:

N1. “This document proposes…” and “The changes proposed here…”.  We’re past the proposal phase: “This document specifies…”

N2. s/ maintaining Verified Resource Set/ maintaining a Verified Resource Set

N3. s/ the loss of on IP address prefix/ the loss of one IP address prefix

N4. s/ the 1988 ASN.1 modules for which we provided an update in Section 4.2.2.7 remain the normative version/ the 1988 ASN.1 modules in Section 4.2.2.7 remain the normative version

N5. s/ Furthermore we wish to note that operators MAY issue separate BGPsec Router Certificates for different ASNs/ Operators MAY issue separate BGPsec Router Certificates for different ASNs

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

"This document proposes an update to the certificate validation
  procedure specified in RFC 6487 that reduces aspects of operational
  fragility in the management of certificates in the RPKI, while
  retaining essential security features."

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

  The discussion for this document was quite vociferous at times, after some author baton passing and re-working of the wording things calmed down and calmer heads prevailed... final discussion was successful.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

This is not a protocol change, but a mechanics change. The existing CA/RP code implementations will support this once published.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd - morrowc@ops-netman.net - Chris Morrow (me)
Reponsible AD - aretana@cisco.com - Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd reviewed this document several times during it's lifetime, provided feedback and text as well.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

no concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

no

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, no outstanding problems/ipr-claims.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

none required.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The final consensus for this document was solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no appeal threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID Nits was run. There are some missing references, we'll clean those up prior to IESG pub request clickage.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal reviews required.

(13) Have all references within this document been identified as
either normative or informative?

they will be by the time the IESG sees it, yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

yes, to RFC6268.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes, RFC6487's algorithm for validation will be adjusted/updated by this proposal.
This is expected.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA picks up 2 action items from this document, updating an SMI registry for PKIX and adding 2 entries to the same PKIX registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no new registries added.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no formal reviews necessary.

Request for posting confirmation emailed to previous authors: "Geoff Huston" , "Carlos Martinez" , "Andrew Newton" , sidr-chairs@ietf.org, "Tim Bruijnzeels" , "George Michaelson" , "Daniel Shaw"