A Protocol for Provisioning Resource Certificates
RFC 6492
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
11 | (System) | Notify list changed from sidr-chairs@ietf.org, draft-ietf-sidr-rescerts-provisioning@ietf.org to (None) |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
2012-02-06 |
11 | Amy Vezza | State changed to RFC Published from RFC Ed Queue. |
2012-02-03 |
11 | (System) | RFC published |
2011-09-27 |
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-09-27 |
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2011-09-06 |
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-08-30 |
11 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-08-29 |
11 | (System) | IANA Action state changed to In Progress |
2011-08-29 |
11 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-08-29 |
11 | Cindy Morgan | IESG has approved the document |
2011-08-29 |
11 | Cindy Morgan | Closed "Approve" ballot |
2011-08-29 |
11 | Cindy Morgan | Approval announcement text regenerated |
2011-08-26 |
11 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Ondřej Surý. |
2011-08-26 |
11 | Stewart Bryant | Ballot writeup text changed |
2011-08-26 |
11 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-11.txt |
2011-08-25 |
11 | Cindy Morgan | Removed from agenda for telechat |
2011-08-25 |
11 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
2011-08-25 |
11 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-25 |
11 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-25 |
11 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-25 |
11 | Stephen Farrell | [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 … [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). |
2011-08-25 |
11 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2011-08-25 |
11 | Stewart Bryant | Ballot writeup text changed |
2011-08-24 |
11 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-24 |
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-24 |
11 | Pete Resnick | [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 … [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"). |
2011-08-24 |
11 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-24 |
11 | Peter Saint-Andre | [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss |
2011-08-24 |
11 | Russ Housley | [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 … [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. |
2011-08-24 |
11 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-22 |
11 | Peter Saint-Andre | [Ballot discuss] As far as I can see at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html the "application/rpki-updown" media type has not undergone the community review required by RFC 4288. |
2011-08-22 |
11 | Peter Saint-Andre | [Ballot Position Update] New position, Discuss, has been recorded |
2011-08-22 |
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-21 |
11 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-08-20 |
11 | Stephen Farrell | [Ballot comment] -- these were discuss points but are ok as comments following discussion Most of these are just checking if the WG thought about … [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. |
2011-08-20 |
11 | Stephen Farrell | [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 … [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). |
2011-08-19 |
11 | Stephen Farrell | [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 … [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. |
2011-08-19 |
11 | Stephen Farrell | [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. … [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. |
2011-08-19 |
11 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2011-08-14 |
11 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-07-19 |
11 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2011-07-19 |
11 | Stewart Bryant | Ballot has been issued |
2011-07-19 |
11 | Stewart Bryant | Created "Approve" ballot |
2011-07-19 |
11 | Stewart Bryant | Placed on agenda for telechat - 2011-08-25 |
2011-07-19 |
11 | Stewart Bryant | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-06-30 |
11 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-06-28 |
11 | Amanda Baber | 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: … 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. |
2011-06-17 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2011-06-17 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2011-06-16 |
11 | Amy Vezza | Last call sent |
2011-06-16 |
11 | Amy Vezza | 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> … 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 |
2011-06-16 |
11 | Stewart Bryant | Ballot writeup text changed |
2011-06-16 |
11 | Stewart Bryant | Last Call was requested |
2011-06-16 |
11 | Stewart Bryant | State changed to Last Call Requested from Publication Requested. |
2011-06-16 |
11 | Stewart Bryant | Last Call text changed |
2011-06-16 |
11 | (System) | Ballot writeup text was added |
2011-06-16 |
11 | (System) | Last call text was added |
2011-06-16 |
11 | (System) | Ballot approval text was added |
2011-06-09 |
10 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-10.txt |
2011-03-31 |
11 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (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. |
2011-03-31 |
11 | Cindy Morgan | Draft added in state Publication Requested |
2011-03-31 |
11 | Cindy Morgan | [Note]: 'Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.' added |
2010-11-11 |
09 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-09.txt |
2010-11-09 |
08 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-08.txt |
2010-10-15 |
07 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-07.txt |
2010-05-07 |
06 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-06.txt |
2010-02-12 |
11 | (System) | Document has expired |
2009-08-12 |
05 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-05.txt |
2009-02-06 |
04 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-04.txt |
2008-08-07 |
03 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-03.txt |
2008-06-20 |
02 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-02.txt |
2008-06-18 |
01 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-01.txt |
2008-01-02 |
00 | (System) | New version available: draft-ietf-sidr-rescerts-provisioning-00.txt |