A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2011-05-31
|
22 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-05-16
|
22 | (System) | IANA Action state changed to No IC from In Progress |
2011-05-16
|
22 | (System) | IANA Action state changed to In Progress |
2011-05-16
|
22 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-05-16
|
22 | Amy Vezza | IESG has approved the document |
2011-05-16
|
22 | Amy Vezza | Closed "Approve" ballot |
2011-05-16
|
22 | Amy Vezza | Approval announcement text regenerated |
2011-05-16
|
22 | Amy Vezza | Ballot writeup text changed |
2011-05-16
|
22 | Amy Vezza | State changed to Approved-announcement to be sent from Waiting for AD Go-Ahead. |
2011-05-05
|
22 | (System) | New version available: draft-ietf-sidr-res-certs-22.txt |
2011-03-29
|
22 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-03-21
|
22 | Alexey Melnikov | [Ballot discuss] [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam] This is a well written document and I generally … [Ballot discuss] [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam] This is a well written document and I generally support its publication. I was originally planning to file a DISCUSS on this issue, but though that the WG knows better. However Sam's SecDir review has changed my mind: Sam wrote: I do not believe the concerns I raised in my secdir review have been addressed and I still have a deep architectural concern with the decision to prevent relying parties from accepting unknown non-critical extensions. There seems to be agreement with several points I raised: 1) The profile does prohibit unknown extensions. 2) I think there is agreement that before we can start using an error correction or new feature, we have to upgrade all software in the wild that might see the certificates. 3) Everyone including me thinks that strong restrictions on what certificates are created is good for this profile. The question is what about restrictions on what people receive. If the IETF changes the standard in the future do we want to have to upgrade issuers and consumers or just issuers before we start using the new spec in what we issue. 4) We may find ourself in a situation where we made a mistake or need to expand what the RPKI does. Adding from myself: I think there is no disagreement that extensions not listed in this profile SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting itself in the foot by making receivers reject certificates with unrecognized non critical extensions. A much better architectural approach would be to say that such non critical extensions "MUST be ignored". This is a pretty standard trick in the Apps Area and allows for safe extensibility. |
2011-03-21
|
22 | Stewart Bryant | Ballot writeup text changed |
2011-03-17
|
22 | Cindy Morgan | Removed from agenda for telechat |
2011-03-17
|
22 | Jari Arkko | [Ballot comment] From Ari Keränen's review: 1. Introduction o a conformation of a public key match between the CRL issuer and … [Ballot comment] From Ari Keränen's review: 1. Introduction o a conformation of a public key match between the CRL issuer and the Resource Certificate issuer is required, and Should that be "confirmation"? |
2011-03-17
|
22 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-17
|
22 | Peter Saint-Andre | [Ballot comment] Although I am provisionally balloting "No Objection" pending discussion within the IESG, I too am concerned about the issues raised in Alexey Melnikov's … [Ballot comment] Although I am provisionally balloting "No Objection" pending discussion within the IESG, I too am concerned about the issues raised in Alexey Melnikov's DISCUSS. |
2011-03-17
|
22 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-17
|
22 | Tim Polk | [Ballot comment] I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not typical for IETF publications. It would be good for the IESG to … [Ballot comment] I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not typical for IETF publications. It would be good for the IESG to discuss the merits and drawbacks of the wg's consensus approach. However, I should note that I personally am comfortable with the approach based on the unique attributes of its intended deployment and application. Various aspects of this problem have been actively discussed since Stockholm. |
2011-03-17
|
22 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-17
|
22 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2011-03-17
|
22 | Alexey Melnikov | [Ballot discuss] [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam] This is a well written document and I generally … [Ballot discuss] [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam] This is a well written document and I generally support its publication. I was originally planning to file a DISCUSS on this issue, but though that the WG knows better. However Sam's SecDir review has changed my mind: Sam wrote: I do not believe the concerns I raised in my secdir review have been addressed and I still have a deep architectural concern with the decision to prevent relying parties from accepting unknown non-critical extensions. There seems to be agreement with several points I raised: 1) The profile does prohibit unknown extensions. 2) I think there is agreement that before we can start using an error correction or new feature, we have to upgrade all software in the wild that might see the certificates. 3) Everyone including me thinks that strong restrictions on what certificates are created is good for this profile. The question is what about restrictions on what people receive. If the IETF changes the standard in the future do we want to have to upgrade issuers and consumers or just issuers before we start using the new spec in what we issue. 4) We may find ourself in a situation where we made a mistake or need to expand what the RPKI does. Adding from myself: I think there is no disagreement that extensions not listed in this profile SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting itself in the foot by making receivers reject certificates with unrecognized non critical extensions. A much better architectural approach would be to say that such non critical extensions "MUST be ignored". This is a pretty standard trick in the Apps Area and allows for safe extensibility. I also have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication: 4.9.6. CRL Distribution Points The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI form of object identification. This needs a Normative reference to the URI RFC. The sequence of distributionPoint values MUST contain only a single DistributionPoint. The DistributionPoint MAY contain more than one URI value. An RSYNC URI [RFC5781] MUST be present in the This makes the reference Normative (and it is a DownRef). DistributionPoint, and reference the most recent instance of this Issuer's CRL. Other access form URIs MAY be used in addition to the RSYNC URI, representing alternate access mechanisms for this CRL. |
2011-03-17
|
22 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
22 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
22 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
22 | David Harrington | [Ballot discuss] 1) can "Valid To" be earlier than "Valid from"? What are the handling proceudres if this occurs? |
2011-03-16
|
22 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection |
2011-03-15
|
22 | Ralph Droms | [Ballot comment] Minor editorial suggestion: In the Abstract, s/Resources (INRs)/Internet Number Resources (INRs)/ |
2011-03-15
|
22 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-15
|
22 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-15
|
22 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-15
|
22 | Amy Vezza | Last call sent |
2011-03-15
|
22 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (A Profile for X.509 PKIX 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 Profile for X.509 PKIX Resource Certificates' 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-03-29. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ This IETF Last Call is to draw the attention of the IETF to an additional downref in the draft that was noted during IESG review. Section 4.9.6 contains a reference to RFC5781. This reference has not been added to the references section of the draft, but will need to be a normative reference. As was noted in the previous IETF Last call this document also has a downref to RFC2986. |
2011-03-15
|
22 | Stewart Bryant | Last Call was requested |
2011-03-15
|
22 | Stewart Bryant | State changed to Last Call Requested from Waiting for AD Go-Ahead. |
2011-03-15
|
22 | Stewart Bryant | Last Call text changed |
2011-03-15
|
22 | Stewart Bryant | Last Call text changed |
2011-03-14
|
22 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-12
|
22 | Alexey Melnikov | [Ballot comment] 4.4. Issuer The value of this field is a valid X.501 distinguished name. A reference to the document defining DNs is needed … [Ballot comment] 4.4. Issuer The value of this field is a valid X.501 distinguished name. A reference to the document defining DNs is needed here. (One of the LDAP documents might do.) An Issuer name MUST contain one instance of the Common Name attribute and MAY contain one instance of the Serial Number attribute. If both attributes are present, it is RECOMMENDED that they appear as a set. The Common Name attribute MUST be encoded as a printable string. Similarly, a reference for printable string is needed. Issuer names are not intended to be descriptive of the identity of Issuer. 4.9.8.1. SIA for CA Certificates The ordering of URIs in this accessDescription sequence reflect the CA's relative preferences for access methods to be used by RPs, with he first s/he/the element of the sequence being the most preferred by the CA. 6.2.1. CRMF Resource Certificate Request Template Fields version This field SHOULD be omitted. If present, it MUST specify a request for a Version 3 Certificate. It Unfinished sentence? |
2011-03-12
|
22 | Alexey Melnikov | [Ballot discuss] This is a well written document and I generally support its publication. I do however have a small list of [nearly] nit-picking items … [Ballot discuss] This is a well written document and I generally support its publication. I do however have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication: 4.9.6. CRL Distribution Points The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI form of object identification. This needs a Normative reference to the URI RFC. The sequence of distributionPoint values MUST contain only a single DistributionPoint. The DistributionPoint MAY contain more than one URI value. An RSYNC URI [RFC5781] MUST be present in the This makes the reference Normative (and it is a DownRef). DistributionPoint, and reference the most recent instance of this Issuer's CRL. Other access form URIs MAY be used in addition to the RSYNC URI, representing alternate access mechanisms for this CRL. |
2011-03-12
|
22 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded |
2011-03-11
|
22 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Sam Hartman. |
2011-03-10
|
22 | Sean Turner | [Ballot comment] Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref "Valid From" should be "Not Before" and "Valid To" should be "Not … [Ballot comment] Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref "Valid From" should be "Not Before" and "Valid To" should be "Not After" to match the name of fields in RFC 5280. |
2011-03-09
|
22 | Sean Turner | [Ballot comment] Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref |
2011-03-09
|
22 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded |
2011-03-09
|
22 | Stewart Bryant | Placed on agenda for telechat - 2011-03-17 by Stewart Bryant |
2011-03-09
|
22 | Stewart Bryant | [Note]: 'Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.' added by Stewart Bryant |
2011-03-09
|
22 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2011-03-09
|
22 | Stewart Bryant | Ballot has been issued |
2011-03-09
|
22 | Stewart Bryant | Created "Approve" ballot |
2011-02-21
|
22 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-02-18
|
22 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-02-16
|
22 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2011-02-16
|
22 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2011-02-07
|
22 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (A Profile for X.509 PKIX 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 Profile for X.509 PKIX Resource Certificates' 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-02-21. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ Please note that this document contains a downref to RFC 2986 |
2011-02-07
|
22 | Stewart Bryant | Ballot writeup text changed |
2011-02-07
|
22 | Stewart Bryant | Last Call was requested |
2011-02-07
|
22 | Stewart Bryant | State changed to Last Call Requested from Publication Requested. |
2011-02-07
|
22 | Stewart Bryant | Last Call text changed |
2011-02-07
|
22 | (System) | Ballot writeup text was added |
2011-02-07
|
22 | (System) | Last call text was added |
2011-02-07
|
22 | (System) | Ballot approval text was added |
2011-02-07
|
22 | Stewart Bryant | Last Call text changed |
2011-02-04
|
22 | 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 IETF70, IETF72, IETF73, IETF76, and IETF79 meetings and went through last call (the last time, it has been through last call before) in Nov 2010 in the working group. Comments received were addressed on the list. 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? This draft was the first draft presented to the working group. Over the years, portions have been extracted to become independent drafts and the language has become more concise as a result of detailed reviews. Implementation experience conveyed by several independent implementors has been a force in the evolution of the draft. The components described here are major components in the RPKI, so authors of any other draft in the working group are certain to have reviewed this draft. The working group as a whole understands the concepts of this draft. (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 reports the following for this draft: Summary: 1 error (**), 9 warnings (==), 3 comments (--). The error is a downref to 2986. As this is intended to be a standards track document and 2986 is Informational, that is a downref. See below. The warnings have to do with absence of 5378 disclaimers (overall issue discussed with ADs) and with outdated references (to overtaken versions of drafts). There is one warning about non-rfc3330 compliant ipv4 addresses. The references are in an example certificate, but as the certificate is supposed to be demonstrating an allocation of addresses and the example IP addresses would not be the subject of an allocation and therefore never incorporated into a certificate, using one of the IPv4 addresses reserved for examples would produce an impossible certificate. There are no formal reviews required for this document. The document mandates a particular URI access mechanism, "rsync". That access mechanism is defined in RFC5781. (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 strategy2 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. This document is intended for Standards status; one of the references is a downward reference to an Informational RFC: RFC 2986. That RFC notes that it is "a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process." In that circumstance, the downref 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, is consistent with the document, 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? This document uses ASN.1 in describing portions of the certificate. The syntax was checked using asn1Parser from the libtasn1-tools package (v2.7.1) and passed. (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 Summmary This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of Resources (INRs). The certificates issued under this profile are used to convey the Issuer's authorisation of the Subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). The document also specifies profiles for the format of certificate requests. The document also specifies the Relying Party RPKI certificate path validation procedure. Working Group Summary This draft was the first draft presented to the working group and has been a basis for other work in the working group. Several implementators of this certificate profile have conveyed implementation experience that has been incorporated into the draft. Document Quality This document is well written and clear. Over the years, portions have been extracted to become independent drafts and the language has become more concise as a result of detailed reviews. Although this profile does not define a protocol, several independent implementations of this certificate profile exist, indicating careful review. There have been careful reviews by X.509 PKI experts and by ASN.1 experts and their comments have been addressed. There is no MIB and there is no Media Type. |
2011-02-04
|
22 | Cindy Morgan | Draft added in state Publication Requested |
2011-02-04
|
22 | Cindy Morgan | [Note]: 'Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.' added |
2010-12-02
|
21 | (System) | New version available: draft-ietf-sidr-res-certs-21.txt |
2010-11-08
|
20 | (System) | New version available: draft-ietf-sidr-res-certs-20.txt |
2010-10-13
|
19 | (System) | New version available: draft-ietf-sidr-res-certs-19.txt |
2010-05-18
|
18 | (System) | New version available: draft-ietf-sidr-res-certs-18.txt |
2010-03-22
|
22 | (System) | Document has expired |
2009-09-15
|
17 | (System) | New version available: draft-ietf-sidr-res-certs-17.txt |
2009-02-25
|
16 | (System) | New version available: draft-ietf-sidr-res-certs-16.txt |
2008-11-17
|
15 | (System) | New version available: draft-ietf-sidr-res-certs-15.txt |
2008-10-25
|
14 | (System) | New version available: draft-ietf-sidr-res-certs-14.txt |
2008-09-18
|
13 | (System) | New version available: draft-ietf-sidr-res-certs-13.txt |
2008-09-06
|
12 | (System) | New version available: draft-ietf-sidr-res-certs-12.txt |
2008-07-31
|
11 | (System) | New version available: draft-ietf-sidr-res-certs-11.txt |
2008-06-16
|
10 | (System) | New version available: draft-ietf-sidr-res-certs-10.txt |
2007-11-13
|
09 | (System) | New version available: draft-ietf-sidr-res-certs-09.txt |
2007-07-30
|
08 | (System) | New version available: draft-ietf-sidr-res-certs-08.txt |
2007-07-03
|
07 | (System) | New version available: draft-ietf-sidr-res-certs-07.txt |
2007-04-10
|
06 | (System) | New version available: draft-ietf-sidr-res-certs-06.txt |
2007-02-26
|
05 | (System) | New version available: draft-ietf-sidr-res-certs-05.txt |
2007-02-21
|
04 | (System) | New version available: draft-ietf-sidr-res-certs-04.txt |
2007-02-13
|
03 | (System) | New version available: draft-ietf-sidr-res-certs-03.txt |
2006-07-28
|
02 | (System) | New version available: draft-ietf-sidr-res-certs-02.txt |
2006-06-22
|
01 | (System) | New version available: draft-ietf-sidr-res-certs-01.txt |
2006-06-09
|
00 | (System) | New version available: draft-ietf-sidr-res-certs-00.txt |