[Ballot discuss]
The original discuss text for this was:

(5) While a sha-1 hash for ski is safe as used in 5280 and in path
processing even if sha-1 were to be (more) broken, I'm not sure
that that's true for use in revocation requests as is done here in
3.5.1. Did the WG consider whether algorithm agility is really
needed for this use of ski? I guess a potential threat would be
if sha-1 were broken for pre-images and a bad client generated a
public key that collides with someone else's public key. That might
be a bit far-fetched but there could also be issues if the hash were
just broken for collisions as well, not sure. I'm happy to be
convinced that this is a non-issue, but adding a hash alg-id to
3.5.1 or asking for a full cert or something might be easier.

Following discussion, we got to this (so far):

In any case I think adding something would be good. Maybe
the equivalent of:

  "The issuer MUST ensure that any certificates to be revoked are
  associated with the requesting client only. Failing to ensure
  this could lead to some attacks in future if the sha-1 were to
  be broken for pre-images."

So, I'm fine to clear with something like that added, or with the
addition of a hash alg-id field to the certificate revocation
request message (which I'd still prefer, in case there are attacks
that weren't thought of).

[Ballot comment]
There are several places throughout the draft where the word "will" gets used in a strange way. I suspect it is just a writing style the authors use, but I wanted to make sure that some of these were not protocol directives, as against simple descriptions of protocol actions:

- Section 3 (note my *hilighting*):

  [...]  The server's response *will* similarly be the body
  of the response with a content type of "application/rpki-updown".

  The content of the POST, and the server's response, *will* be a "well-
  formed" CMS [RFC5652] object, encoded using the Distinguished
  Encoding Rules for ASN.1 (DER) [X.509-88], formatted in accordance
  with the CMS profile specified in the following section. [...]

  The protocol's request / response interaction is assumed to be
  reliable, in that all requests *will* generate a matching response.

For example, in the first, do you simply mean, "The server's response is the body of the response", or do you rather mean, "The server's response MUST be the body of the response"? In other words, are you giving directions to generating implementations here, or simply describing behavior that receiving implementations can expect?

I found similar examples in 3.3.2 (the two paragraphs after the payload definition and the last sentences of the descriptions of resource_set_as, resource_set_ipv4, resource_set_ipv6, [issuer's certificate]), 3.4.1 ("will (re)set the issuer's local record"), 3.6 ("will make a best effort" -- which sounds like a SHOULD -- and "The en-US description will always be included").

[Ballot comment]
The Gen-ART Review by Vijay Gurbani on 23-Aug-2011 includes an
  editorial suggestion:

  I think it will be helpful to identify either in the Abstract or in
  Terminology section what exactly is a "resource".  I do not think you
  mean traditional HTTP resources like files or dynamically generated
  content, etc.

[Ballot comment]
-- these were discuss points but are ok as comments following discussion
Most of these are just checking if the WG thought about stuff so
should be easily cleared up, except maybe the last one.

(1) In 3.1.1.4 the verifier is expected to be able to find CA certs
that aren't supplied. I'm not trying to insist on any particular thing
here, but the more you specify for this the easier it is to get interop
so did the WG consider e.g. insisting that if any CA certs are supplied
then there must be a complete path in some specific order or
something like that? The same thing applies for crls - if its
possible to be more specific then that's better. If the WG thought
about this, and the use cases are such that you can't really say
more here, then that's ok but I wanted to check.

(2) 3.1.1.5 says the crls field MUST be present. That would
preclude a signer that never sees CRLs that might include their
cert. Is that intentional? Is it a good idea? (I'll clear if you say
yes to both but wanted to check.)

(3) In 3.1.2 you say again that the crls field has to be there, but
you never say that it has to contain a reasonable CRL - would it be
ok if I added some random CRL to this field that has nothing to do
with my signer cert? (Assuming the verifier finds the right CRLs
somehow.)

(4) You don't say that the [Binary]SigningTime has to be within the
EE cert validity, nor that it can be outside the EE cert validity.
I don't mind which you want, but saying what's allowed there would
be good. If anything is allowed, then saying that would
be good too. Without having checked, I think I recall some other PKI
implementations that have been over strict or overly loose in this
respect in the past which led to some interop glitches.

-- these are the original comments

1) This has a relatively baroque layering, with HTTP carrying CMS
containing XML possibly containing pkcs#10 etc. I guess that design
is driven by the availability of tools and libraries for those. If
so, it'd be good to say that (and maybe even hint where to get such
tools, not sure) so the reader gets the right impression. If not,
then I'm left wondering why a new protocol doing all that with one
encoding scheme (ASN.1 or XML or whatever) wouldn't have been
a good bit simpler.

(2) The abstract just talks about "resources" but for sidr those are
just routing and addressing information (or however you like to put
it) and not e.g. web resources. It'd be better maybe to make that
clear in the abstract in case someone picks up this RFC and thinks
they can use it for other things. (I know its clear when you get
to section 2, but it'd be nice to save people having to read that
far if they're not going to be able to use this.)

(3) In 3.1.1.4 you say that certificates MUST contain the signer
cert but you don't say it can't contain two certs for
the signer. Later in 3.1.1.6.2 you do say the sid MUST have the
skid from "the" EE cert and in 3.1.2 you say there has to be just
one, but saying so would be nice in 3.1.1.4 as well.

(4) You say that SigningTime and BinarySigningTime have to represent
the same time. I didn't check the references to be sure but do e.g.
the equivalents for "20110819"  and "201108191614" represent the
same time or not? If both have to be at 1-second granularity or
something then just saying that here would be good.

(5) What is an "operator alert error"? (in 3.2) Maybe just "error"
is enough or it ought be defined?

(6) Checks 1, 4, 5 and 6 from 3.2 (p15) replicate stuff from 3.1
which seem unnecessary.

(7) In 3.2, check 3 you say "this server's" which seems wrong for
the case where the client is checking a response.

(8) The end of p22 is the first place it says that you can't use the
same key pair for >1 resource. Could you could add a reference to
some other sidr document that describes this in more detail? It
might also be useful to state this rule earlier.

(9) 3.3 could really do with some overview text saying briefly who
sends what to whom and why. For example, in 3.3.2 it is not clear
whether the client is asking the server for a list belonging to
the client or to the server, at least not until I parsed the fairly
hard-to-get text at the end of p17;-) That overview text might
all be in some other sidr document, but having it here would
be good.

[Ballot discuss]
The original discuss text for this was:

(5) While a sha-1 hash for ski is safe as used in 5280 and in path
processing even if sha-1 were to be (more) broken, I'm not sure
that that's true for use in revocation requests as is done here in
3.5.1. Did the WG consider whether algorithm agility is really
needed for this use of ski? I guess a potential threat would be
if sha-1 were broken for pre-images and a bad client generated a
public key that collides with someone else's public key. That might
be a bit far-fetched but there could also be issues if the hash were
just broken for collisions as well, not sure. I'm happy to be
convinced that this is a non-issue, but adding a hash alg-id to
3.5.1 or asking for a full cert or something might be easier.

Following discussion, we got to this (so far):

In any case I think adding something would be good. Maybe
the equivalent of:

  "The issuer MUST ensure that any certificates to be revoked are
  associated with the requesting client only. Failing to ensure
  this could lead to some attacks in future if the sha-1 were to
  be broken for pre-images."

So, I'm fine to clear with something like that added, or with the
addition of a hash alg-id field to the certificate revocation
request message (which I'd still prefer, in case there are attacks
that weren't thought of).

[Ballot comment]
(1) This has a relatively baroque layering, with HTTP carrying CMS
containing XML possibly containing pkcs#10 etc. I guess that design
is driven by the availability of tools and libraries for those. If
so, it'd be good to say that (and maybe even hint where to get such
tools, not sure) so the reader gets the right impression. If not,
then I'm left wondering why a new protocol doing all that with one
encoding scheme (ASN.1 or XML or whatever) wouldn't have been
a good bit simpler.

(2) The abstract just talks about "resources" but for sidr those are
just routing and addressing information (or however you like to put
it) and not e.g. web resources. It'd be better maybe to make that
clear in the abstract in case someone picks up this RFC and thinks
they can use it for other things. (I know its clear when you get
to section 2, but it'd be nice to save people having to read that
far if they're not going to be able to use this.)

(3) In 3.1.1.4 you say that certificates MUST contain the signer
cert but you don't say it can't contain two certs for
the signer. Later in 3.1.1.6.2 you do say the sid MUST have the
skid from "the" EE cert and in 3.1.2 you say there has to be just
one, but saying so would be nice in 3.1.1.4 as well.

(4) You say that SigningTime and BinarySigningTime have to represent
the same time. I didn't check the references to be sure but do e.g.
the equivalents for "20110819"  and "201108191614" represent the
same time or not? If both have to be at 1-second granularity or
something then just saying that here would be good.

(5) What is an "operator alert error"? (in 3.2) Maybe just "error"
is enough or it ought be defined?

(6) Checks 1, 4, 5 and 6 from 3.2 (p15) replicate stuff from 3.1
which seem unnecessary.

(7) In 3.2, check 3 you say "this server's" which seems wrong for
the case where the client is checking a response.

(8) The end of p22 is the first place it says that you can't use the
same key pair for >1 resource. Could you could add a reference to
some other sidr document that describes this in more detail? It
might also be useful to state this rule earlier.

(9) 3.3 could really do with some overview text saying briefly who
sends what to whom and why. For example, in 3.3.2 it is not clear
whether the client is asking the server for a list belonging to
the client or to the server, at least not until I parsed the fairly
hard-to-get text at the end of p17;-) That overview text might
all be in some other sidr document, but having it here would
be good.

[Ballot discuss]
Most of these are just checking if the WG thought about stuff so
should be easily cleared up, except maybe the last one.

(1) In 3.1.1.4 the verifier is expected to be able to find CA certs
that aren't supplied. I'm not trying to insist on any particular thing
here, but the more you specify for this the easier it is to get interop
so did the WG consider e.g. insisting that if any CA certs are supplied
then there must be a complete path in some specific order or
something like that? The same thing applies for crls - if its
possible to be more specific then that's better. If the WG thought
about this, and the use cases are such that you can't really say
more here, then that's ok but I wanted to check.

(2) 3.1.1.5 says the crls field MUST be present. That would
preclude a signer that never sees CRLs that might include their
cert. Is that intentional? Is it a good idea? (I'll clear if you say
yes to both but wanted to check.)

(3) In 3.1.2 you say again that the crls field has to be there, but
you never say that it has to contain a reasonable CRL - would it be
ok if I added some random CRL to this field that has nothing to do
with my signer cert? (Assuming the verifier finds the right CRLs
somehow.)

(4) You don't say that the [Binary]SigningTime has to be within the
EE cert validity, nor that it can be outside the EE cert validity.
I don't mind which you want, but saying what's allowed there would
be good. If anything is allowed, then saying that would
be good too. Without having checked, I think I recall some other PKI
implementations that have been over strict or overly loose in this
respect in the past which led to some interop glitches.

(5) While a sha-1 hash for ski is safe as used in 5280 and in path
processing even if sha-1 were to be (more) broken, I'm not sure
that that's true for use in revocation requests as is done here in
3.5.1. Did the WG consider whether algorithm agility is really
needed for this use of ski? I guess a potential threat would be
if sha-1 were broken for pre-images and a bad client generated a
public key that collides with someone else's public key. That might
be a bit far-fetched but there could also be issues if the hash were
just broken for collisions as well, not sure. I'm happy to be
convinced that this is a non-issue, but adding a hash alg-id to
3.5.1 or asking for a full cert or something might be easier.

IANA understands that, upon approval of this document, there is a single
action which IANA must complete.

In the application media types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

the following application media type will be added to the registry as
follows:

rpki-updown

with a reference of [ RFC-to-be ].

IANA understands that this is the only IANA action which needs 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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <sidr@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-sidr-rescerts-provisioning-10.txt> (A Protocol for Provisioning Resource Certificates) to Proposed Standard

The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'A Protocol for Provisioning Resource Certificates'
  <draft-ietf-sidr-rescerts-provisioning-10.txt> as a 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 2011-06-30. 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 defines a framework for certificate management
  interactions between a resource issuer ("Issuer") and a resource
  recipient ("Subject") through the specification of a protocol for
  interaction between the two parties.  The protocol supports the
  transmission of requests from the Subject, and corresponding
  responses from the Issuer encompassing the actions of certificate
  issuance, certificate revocation and certificate status information
  reports.  This protocol is intended to be limited to the application
  of resource certificate management and is not intended to be used as
  part of a more general certificate management framework.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-rescerts-provisioning/

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

Two downrefs occur in this document:  RFC2986 and RFC5781.

RFC5781 is already registered in the downref registry:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Sandra Murphy, sidr co-chair.  The document
shepherd has personally reviewed the document.  No issues were
discovered that would prevent advancement.  This document is ready
for forwarding to the IESG.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has had adequate review.  It was presented at working
group meetings at the IETF 70, IETF 72, IETF 76 and IETF 79 meetings.
It has been implemented by several of the RPKI implementors
(proof that they reviewed the document) and any implementation
experience has been brought to the working group.  It went through
working group last call in Nov 2010.  Comments received in last
call were easily addressed.

The draft went through last call in Nov 2010 in the working group.
Responses were strongly positive; only one comment was received and
was quickly resolved. There was adequate support from the working
group to indicate broad interest.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No, the document shepherd has no concerns about this document.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The document shepherd has no concerns with advancing this document. No
IPR claims have been filed against this document.

  (1.e) 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 working group has participated actively in presentations of this
document.  The last call response indicated broad interest.  Multiple
implementations of this protocol exist, and the implementors are active
wg members. This protocol is supported by some RIRs and promised by
others, as it provides a feature that provides for full participation
in RPKI by ISPs who want to directly manage their own resources.  The
wg as a whole understands the protocol, especially the part it plays in the
RPKI.

  (1.f) 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
        entered into the ID Tracker.)

No appeals have been issued or threatened for this document.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The tools site idnits reports the following for this draft:

      Summary: 2 errors (**), 3 warnings (==), 3 comments (--).

The errors are downrefs in two Informational normative references:
RFC 2986 and RFC 5781.

The lesser errors are due to dates related to the draft.

The document shepherd was told that there is an XML doctor just as
their is a MIB doctor. The Apps ADs were queried about required process
for consulting an XML doctor.  Their response wass that there is not a
formal process, but an expert could be found if there were concerns
about the XML. The document shepherd has no concerns about the XML (it
is implemented and used, so it is at least useable), so no review was done.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes, the document has split its references into normative and informative
sections.  This document relies normatively on several other
working group documents that are either advancing at the same time or
have been through last call and are awaiting final versions addressing
minor comments in order to advance.

There are two downrefs to Informational normative references:
RFC 2986 and RFC 5781.  RFC 2986 is the specification of PKCS #10.
That RFC is Informational as it was developed outside the IETF. RFC
5781 is the specification of the "rsync" URI.  The rsync URI is a
mandated to appear in some protocol messages, and so the normative
reference is appropriate.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section exists and does not create a new
registry or entries in an existing registry.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document contains an XML schema definition in Appendix B.  The
XML validators mentioned on the tools site
http://tools.ietf.org/inventory/verif-tools were not able to load
the name space for the schema.  This is probably due to unfamiliarity
on the part of the shepherd with XML schema and the tools.

  (1.k) 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.
      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?
      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?

Technical Summary

This document defines a framework for certificate management
interactions between a resource issuer ("Issuer") and a resource
recipient ("Subject") through the specification of a protocol for
interaction between the two parties.  The protocol supports the
transmission of requests from the Subject, and corresponding
responses from the Issuer encompassing the actions of certificate
issuance, certificate revocation and certificate status information
reports.  This protocol is intended to be limited to the application
of resource certificate management and is not intended to be used as
part of a more general certificate management framework.

Working Group Summary

The working group progress with this draft has been smooth.  The most
contentious issue related to the use of TLS in the protocol.  While the
use of TLS seemed to be a generally good idea, the operational
difficulties reported by users and implementers and the lack of any clear
benefit from TLS convinced the working group to remove it from the protocol.

Document Quality

The document is well written and clear. There are independent
implementations of this protocol and planned implementations, not by
vendors but by RIRs who are the critical deployment points of this
protocol.

There is no MIB and there is no Media Type.