Server-Based Certificate Validation Protocol (SCVP)
RFC 5055
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
33 | (System) | Changed document authors from "Dave Cooper, Russ Housley, Ambarish Malpani, Trevor Freeman" to "Dave Cooper, Russ Housley, Ambarish Malpani, Trevor Freeman, William Polk" |
|
2015-10-14
|
33 | (System) | Notify list changed from pkix-chairs@ietf.org, housley@vigilsec.com to (None) |
|
2012-08-22
|
33 | (System) | post-migration administrative database adjustment to the No Objection position for Lisa Dusseault |
|
2012-08-22
|
33 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
|
2012-08-22
|
33 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
|
2008-01-31
|
33 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2008-01-31
|
33 | Amy Vezza | [Note]: 'RFC 5055' added by Amy Vezza |
|
2007-12-12
|
33 | (System) | RFC published |
|
2007-09-26
|
33 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-09-25
|
33 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-09-25
|
33 | Amy Vezza | IESG has approved the document |
|
2007-09-25
|
33 | Amy Vezza | Closed "Approve" ballot |
|
2007-09-25
|
33 | Sam Hartman | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Sam Hartman |
|
2007-09-25
|
33 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
|
2007-09-21
|
33 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault |
|
2007-09-21
|
33 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2007-09-21
|
33 | (System) | New version available: draft-ietf-pkix-scvp-33.txt |
|
2007-09-11
|
33 | Sam Hartman | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Sam Hartman |
|
2007-07-11
|
33 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
|
2007-07-08
|
33 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2007-07-08
|
32 | (System) | New version available: draft-ietf-pkix-scvp-32.txt |
|
2007-04-06
|
33 | (System) | Removed from agenda for telechat - 2007-04-05 |
|
2007-04-05
|
33 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Carl Wallace. |
|
2007-04-05
|
33 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Amy Vezza |
|
2007-04-05
|
33 | Sam Hartman | [Ballot discuss] * Mime types review needs to be performed for the mime types in appendix a. From the secdir review by Carl Wallace: - … [Ballot discuss] * Mime types review needs to be performed for the mime types in appendix a. From the secdir review by Carl Wallace: - In section 3.2.2, servers are prohibited from providing status of additional checks that were performed. Section 4.9.4 permits servers to include information from additional checks to more fully describe error conditions. Please resolve this conflict. - Why are the rules introduced in the list in section 4 necessary? The protectResponse text should be sufficient. Item 3 is inconsistent with the protectResponse section and with section 4 paragraph 4. [I'm particularly concerned about the inconsistency; extra rules are not blocking.] - The last sentence of section 3.2.4.1 states that servers "MAY be able to process valPolParams". This should probably be a MUST for all validation policies that use parameters. From Spencer's genart review: > Conforming client implementations MUST be able to assert at least one > of the standard checks. Conforming clients MAY be able to assert > multiple checks. Conforming clients need not support all of the > checks defined in this section. Spencer: I'm somewhat confused by "MUST/MAY be able to assert" - is "be able to" really a 2119 requirement? I would be more comfortable with "MUST support at least one of the standard checks" and "MAY assert multiple checks". I'd prefer to fix this throughout. I would of course ask the working group to look at all the secdir and genart comments but these are the ones I consider blocking. |
|
2007-04-05
|
33 | Sam Hartman | [Ballot discuss] * Mime types review needs to be performed for the mime types in appendix a. From the secdir review by Carl Wallace: - … [Ballot discuss] * Mime types review needs to be performed for the mime types in appendix a. From the secdir review by Carl Wallace: - In section 3.2.2, servers are prohibited from providing status of additional checks that were performed. Section 4.9.4 permits servers to include information from additional checks to more fully describe error conditions. Please resolve this conflict. - Why are the rules introduced in the list in section 4 necessary? The protectResponse text should be sufficient. Item 3 is inconsistent with the protectResponse section and with section 4 paragraph 4. [I'm particularly concerned about the inconsistency; extra rules are not blocking.] - The last sentence of section 3.2.4.1 states that servers "MAY be able to process valPolParams". This should probably be a MUST for all validation policies that use parameters. From Spencer's genart review: > Conforming client implementations MUST be able to assert at least one > of the standard checks. Conforming clients MAY be able to assert > multiple checks. Conforming clients need not support all of the > checks defined in this section. Spencer: I'm somewhat confused by "MUST/MAY be able to assert" - is "be able to" really a 2119 requirement? I would be more comfortable with "MUST support at least one of the standard checks" and "MAY assert multiple checks". I'd prefer to fix this throughout. I would of course ask the working group to look at all the secdir and genart comments but these are the ones I consider blocking. |
|
2007-04-05
|
33 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Discuss from Yes by Sam Hartman |
|
2007-04-05
|
33 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
|
2007-04-04
|
33 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2007-04-04
|
33 | Cullen Jennings | [Ballot comment] I wanted to note to the authors/ads that this did not seem to have a Name Validation ALgorithm that would work for SIP. … [Ballot comment] I wanted to note to the authors/ads that this did not seem to have a Name Validation ALgorithm that would work for SIP. I don't see any problems with a future document extending this to have one that does work for SIP, so I'm not worried about this - It would be easy to add one if people felt that would be valuable in this document. There are people that want to build phones that delegate this type of checking to a trusted server. |
|
2007-04-04
|
33 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2007-04-04
|
33 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2007-04-04
|
33 | Tim Polk | [Ballot Position Update] New position, Recuse, has been recorded by Tim Polk |
|
2007-04-04
|
33 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2007-04-04
|
33 | Lisa Dusseault | [Ballot discuss] I'm focusing on the use of HTTP as you might expect. The HTTP appendix has a small number of normative statements. It doesn't … [Ballot discuss] I'm focusing on the use of HTTP as you might expect. The HTTP appendix has a small number of normative statements. It doesn't meet our normal expectations for ensuring interoperability. Any interoperability that is achieved will be through the choices of the early implementors, turning into de facto standards. The spec needs to say whether support for scvp-cv-request and scvp-vp-request are REQUIRED. I believe that this spec is descriptive rather than normative on basic issues like this. Here's some of what I'd like added wrt HTTP (this is the actionable part of the DISCUSS). - HTTP has got to be a normative reference. - If HTTP is the only transport defined, then for interoperability I suggest that HTTP should be mandatory-to-implement. That would make this not an appendix, but a normal section of the document. - Clearly SCVP clients can choose whether to support the HTTP transport at all, but when they do, are they required to be full HTTP 1.1 clients? This would imply supporting chunked transfer-encoding, persistent connections (or the Connection: Close header) and redirects, for example. - Define the success response code to the POST requests. I'd assume 200 OK but there are other possibilities. - Define the possible failure modes and appropriate status codes for those. - REQUIRE clients to support both HTTP and HTTP+TLS, in order to handle any kind of SCVP URL encountered. Now for the non-actionable (yet) part of the DISCUSS, the part that requires further discussion: - We probably need to start the difficult discussion of full HTTP support on the resources defined here. Any HTTP resource is supposed to respond reasonably to OPTIONS, GET, pipelining, headers including Accept and other negotiation headers, the conditional headers If-Modified-Since vs. If-Unmodified-Since. Some of these features are unsupported even in normal HTTP servers when the URL points to a dynamic resource, so it's really common practice to fail to comply with some of these. Still, we're about to set a precedent here, and I'm aware of other proposals to layer similar protocols on HTTP. - SCVP layers its own caching support on top of HTTP. This may be the correct choice if there are really going to be other transports. However, I believe that SCVP could simplify its internal logic if it were willing to use HTTP cache and conditional logic instead. - Is there any expectation of client authentication or are clients really expected to be anonymous? - The document says nothing about how SCVP validation URLs are obtained. Chris thought it might be via configuration; Ekr suggested it might be found in a certificate. I'd like at least discussion on this point, and resolving might involve talking about what kind of URLs can appear wherever they appear (HTTP and HTTPS to start with) - I'd like to know more about how SCVP HTTP URLs are structured. What would the path structure or parameters look like? Are query parameters allowed? Are there likely to be many URLs per SCVP server or just one or two? Both cases seem strange to me. I am not sure what an SCVP server would use many URLs for, but OTOH if only a couple URLs on the server are ever used that seems like a bad match for HTTP's features. |
|
2007-04-04
|
33 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
|
2007-04-03
|
33 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2007-04-03
|
33 | Chris Newman | [Ballot comment] It's my opinion this is so complex it's not likely to be widely deployed. As a result, the failure to conform to IETF … [Ballot comment] It's my opinion this is so complex it's not likely to be widely deployed. As a result, the failure to conform to IETF BCP 56 is unlikely to have negative repercussions significant enough to merit a DISCUSS vote. Regardless, this document could be improved by conforming to IETF BCP 56 -- specifically by registering a separate port for SCVP over HTTP, considering an SCVP URL scheme and providing mention of how this interacts with HTTP proxies in the security considerations section. There have also been a great deal of security vulnerabilities in real world security products due to the use of ASN.1. The security considerations of this document should provide a reference or text covering the security considerations of using ASN.1. It is also not clear to me how this mechanism bootstraps. It seems the client has to be manually configured with an HTTP URL (or other URL scheme) which will vary unpredicably from site to site and sufficient information to verify the server signature on the response packet. In my experience, requiring more client bootstrap info than a server DNS name is likely to be a barrior to deployment outside of well-managed enclaves. A few nits: In section 3.2 where it summarizes the structure elements, it fails to mention the producedAt element. In section 3.2.2, it requires SCVP servers that conform to DPD to implement id-stc-build-pkc-path, and DPV compliant SCVP servers to implement the other two checks. What about an SCVP server that conforms to neither DPD nor DPV? Would it be a compliant SCVP server if it implemented no checks? Section 3.2.4.2.2, the order of the final three paragraphs does not match the order of the items in the structure; moving the last paragraph up two would fix that. Section 3.2.4.2.3, Does *.a.com match a.com? I assume not, but the text would be better if it said so. |
|
2007-04-03
|
33 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2007-04-03
|
33 | Magnus Westerlund | [Ballot discuss] Okay, this is me playing applications AD. I can't find that the Media types has gone though review on the ietf-types list. This … [Ballot discuss] Okay, this is me playing applications AD. I can't find that the Media types has gone though review on the ietf-types list. This is a requirement, see RFC 4289 and http://www1.tools.ietf.org/group/iesg/trac/wiki/MediaTypes |
|
2007-04-03
|
33 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
|
2007-04-02
|
33 | Chris Newman | |
|
2007-04-02
|
33 | Chris Newman | [Ballot Position Update] Position for Chris Newman has been changed to Abstain from Discuss by Chris Newman |
|
2007-04-02
|
33 | Chris Newman | [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman |
|
2007-04-02
|
33 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2007-04-02
|
33 | Yoshiko Fong | IANA Additional comments: "id-pkix" appears in several RFCs beginning with RFC 2459 and is defined as follows: id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) … IANA Additional comments: "id-pkix" appears in several RFCs beginning with RFC 2459 and is defined as follows: id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } It appears that in draft-ietf-pkix-scvp-31.txt, the definition of the arc is written in long form rather than using the "id-pkix" abbreviation. In order to avoid any confusion, I will replace the line that reads id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } with id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } |
|
2007-03-30
|
33 | Russ Housley | [Ballot Position Update] New position, Recuse, has been recorded by Russ Housley |
|
2007-03-30
|
33 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
|
2007-03-30
|
33 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Carl Wallace |
|
2007-03-30
|
33 | Yoshiko Fong | IANA Last Call Comments; Question: In section 3.11 there is a reference to id-pkix which isn't mentioned anywhere else in the document. What does this … IANA Last Call Comments; Question: In section 3.11 there is a reference to id-pkix which isn't mentioned anywhere else in the document. What does this refer to? I believe this does not affect IANA. Upon approval of this document IANA will make the following MIME-Type registrations in the "applications" mime-type registry at: http://www.iana.org/assignments/media-types/application/index.html Action 1: Register the "application/scvp-cv-request" mime type as described in section A.1 of RFC-pkix-scvp-31. Action 2: Register the "application/scvp-cv-response" mime type as described in section A.2 of RFC-pkix-scvp-31. Action 3: Register the "application/scvp-vp-request" mime type as described in section A.3 of RFC-pkix-scvp-31. Action 4: Register the "application/scvp-vp-response" mime type as described in section A.4 of RFC-pkix-scvp-31. We understand the above to be the only IANA Actions for this document. |
|
2007-03-29
|
33 | Sam Hartman | [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman |
|
2007-03-29
|
33 | Sam Hartman | Ballot has been issued by Sam Hartman |
|
2007-03-29
|
33 | Sam Hartman | Created "Approve" ballot |
|
2007-03-29
|
33 | Sam Hartman | Placed on agenda for telechat - 2007-04-05 by Sam Hartman |
|
2007-03-29
|
33 | Sam Hartman | 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this … 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Tim Polk, a former PKIX chair, is a co-author, so I (Steve Kent) have personally reviewed the document in my role as the other co-chair. I feel is it ready for publication, modulo minor copy editing improvements. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? This document has undergone a thorough review. It is in its 23rd iteration, having been revised in response to numerous comments from PKIX WG members via the mail list over several YEARS! Most recently I requested the authors to review the document relative to RFC 3379, which established the requirements for any protocol that the WG adopted to fulfill the need for delegated path discovery/validation. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No issues at this stage. 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 development of a standard for delegated path discovery/validation has been contentious since the WG began to tackle the topic over 4 years ago. Several protocols were proposed initially, prompting the WG to develop a requirements document. Each proposal was then compared to the requirements document (RFC 3379, September, 2002) and a straw poll was conducted via the mailing list to select the winner. One proposal, SCVP, received by far the most support, and work continued on it to ensure that all of the requirements were accommodated. (None of the proposals satisfied all of the requirements.) Successive revisions were produced, but at a slow pace, and eventually the document editor was replaced. In the last six month proponents of two of the unsuccessful proposals began complaining about SCVP on the mailing list, saying that it did not meet all of the established requirements and that it introduced features not called for by RFC 3379. This prompted me to require the SCVP authors to produce a matrix showing how each requirement from 3379 was satisfied, and to show that SCVP did not include substantial additional features. At the same time I required the two detractors to produce their own versions of this matrix. The SCVP authors complied with my request and made some minor changes as a result; the detractors did not comply. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. See my commentary above. 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). The I-D nits program was unable to complete a verbose review in several attempts. However, it did note the following minor problems - lack of an IANA considerations section (which will be null) - the author's addresses were buried in Appendix C - the RFC 2119 boilerplate was not present the authors can fix these in the AUTH 48 interval. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The references have been divided as required. All normative references are to RFCs, plus one FIPS. --------------------------------------------------------------------------- Document Write-up Technical Summary The development of SCVP was motivated by two observations: - A growing number of applications that may make use of PKI technology may reside in devices that do not have substantial processing power or that have limited connectivity, e.g., small wireless devices such as cell phones. - Even if a PKI application resides on a full-featured device with good connectivity, e.g., a PC with broadband network access, it may be difficult to manage all of the parameters needed to ensure that certificates are processed in a fashion consistent with enterprise policies. SCVP also supports historical validation, something that many applications and client certificate processing functions do not enable. Specifically, a client can ask whether a specified certificate was valid at a prior point in time, in support of applications where non-repudiation is employed. These observations suggest a need for a standard protocol that allows for an application to delegate the processes of certificate path discovery and/or validation to a server. SCVP provides both services to applications. SCVP assumes that such servers are known to clients (e.g., generally pre-configured) and that each client is configured to invoke either the path discovery or the path validation process according to local policy. Depending on the functionality of the client, server response validation may be effected either through use of a certificate for the server (which presumes some level of client certificate processing ability), or by use of a configured key for the server (either a public key or a pairwise-disjoint, symmetric key for MAC-based authentication). Different applications may request the same path discovery/validation services, but relative to different sets of constraints sent to the server. The policy is specified by an OID and a set of parameters. SCVP distinguishes between a validation algorithm and a validation policy. The default algorithm is the one defined by PKIX RFC 3280, but others, e.g., application-specific algorithms) may be defined in the future. A validation policy OID specifies the algorithm and some or all of the parameters needed as inputs to the algorithm. Default values for the policy may be overridden (if allowed by the policy) by the client, by including them in the validation request. SCVP does NOT specify how to configure and manage policy data on servers; that is a local matter. This design allows local administrators to define and manage different policies for different applications in a centralized fashion. Such distinctions are essential because a certificate is not intrinsically valid; it is valid relative to the requirements imposed by an application in a specific context. For example, one must specify the trust anchors relative to which a certificate is to be validated, the KeyUsage and ExtendedKeyUsage extensions that may be required, certificate policies that may be mandated, etc. SCVP accommodates this complex set of requirements that may be relevant to use of a certificate in a specified context and application, while presenting a simple interface for applications and application developers. It also accommodates applications that want to perform certificate validation, but want a server to do the "heavy lifting" associated with certificate path discovery and the acquisition of revocation status data. All currently-defined, standard forms of revocation status data are accommodated: CRLs (full, delta, and indirect) as well as OCSP responses. On the server side, SCVP allows centralized administration of the certificate path building and/or validation process, and accommodates chaining among servers devoted to this purpose. SCVP uses a simple request/response model. It is largely transport agnostic, but it is anticipated that HTTP will commonly be employed between client and server. The intrinsic security services required for SCVP are provided internal to the protocol, but if a secure transport is used, e.g., TLS, then some of the services can be delegated to a lower layer. For example, authentication of a response from a server can be effected via HTTPS/TLS. The spec includes detailed rules on what responses need to be protected and how, based on the nature of the response (including error responses) and on client-specified request parameters. The implications of different choices of request/response protection options are discussed in detail in the Security Considerations section. Working Group Summary The working group expressed consensus to advance the draft to Proposed Standard. Protocol Quality This document has been reviewed by members of the ietf-pkix@imc.org mailing list and by the working group chairs. The protocol seems reasonable. |
|
2007-03-29
|
33 | Sam Hartman | Removed from agenda for telechat - 2007-04-05 by Sam Hartman |
|
2007-03-29
|
33 | Sam Hartman | Placed on agenda for telechat - 2007-04-05 by Sam Hartman |
|
2007-03-16
|
33 | Amy Vezza | Last call sent |
|
2007-03-16
|
33 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2007-03-15
|
33 | Sam Hartman | Last Call was requested by Sam Hartman |
|
2007-03-15
|
33 | Sam Hartman | State Changes to Last Call Requested from AD Evaluation::AD Followup by Sam Hartman |
|
2007-03-15
|
33 | (System) | Ballot writeup text was added |
|
2007-03-15
|
33 | (System) | Last call text was added |
|
2007-03-15
|
33 | (System) | Ballot approval text was added |
|
2007-01-15
|
31 | (System) | New version available: draft-ietf-pkix-scvp-31.txt |
|
2006-12-27
|
30 | (System) | New version available: draft-ietf-pkix-scvp-30.txt |
|
2006-12-22
|
29 | (System) | New version available: draft-ietf-pkix-scvp-29.txt |
|
2006-10-19
|
33 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-10-19
|
28 | (System) | New version available: draft-ietf-pkix-scvp-28.txt |
|
2006-08-11
|
33 | Sam Hartman | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Sam Hartman |
|
2006-07-29
|
33 | Sam Hartman | AD review completed. Need to write up comments and send to pkix working grou. |
|
2006-07-29
|
33 | Sam Hartman | State Change Notice email list have been change to pkix-chairs@tools.ietf.org, housley@vigilsec.com from pkix-chairs@tools.ietf.org |
|
2006-06-26
|
27 | (System) | New version available: draft-ietf-pkix-scvp-27.txt |
|
2006-06-19
|
26 | (System) | New version available: draft-ietf-pkix-scvp-26.txt |
|
2006-05-26
|
25 | (System) | New version available: draft-ietf-pkix-scvp-25.txt |
|
2006-05-26
|
33 | Sam Hartman | State Changes to AD Evaluation from Publication Requested by Sam Hartman |
|
2006-05-25
|
24 | (System) | New version available: draft-ietf-pkix-scvp-24.txt |
|
2006-05-05
|
33 | Sam Hartman | Draft Added by Sam Hartman in state Publication Requested |
|
2006-03-03
|
23 | (System) | New version available: draft-ietf-pkix-scvp-23.txt |
|
2006-01-23
|
22 | (System) | New version available: draft-ietf-pkix-scvp-22.txt |
|
2005-10-25
|
21 | (System) | New version available: draft-ietf-pkix-scvp-21.txt |
|
2005-08-12
|
20 | (System) | New version available: draft-ietf-pkix-scvp-20.txt |
|
2005-07-20
|
19 | (System) | New version available: draft-ietf-pkix-scvp-19.txt |
|
2005-06-16
|
(System) | Posted related IPR disclosure: CoreStreet, Ltd. Statement about IPR claimed in IETF's draft Simple Certificate Validation Protocol - draft-ietf-pkix-scvp-18 ( | |
|
2005-03-25
|
(System) | Posted related IPR disclosure: CoreStreet, Ltd.'s statement about IPR claimed in draft-ietf-pkix-scvp-18 | |
|
2005-02-21
|
18 | (System) | New version available: draft-ietf-pkix-scvp-18.txt |
|
2005-02-14
|
17 | (System) | New version available: draft-ietf-pkix-scvp-17.txt |
|
2004-10-26
|
16 | (System) | New version available: draft-ietf-pkix-scvp-16.txt |
|
2004-07-20
|
15 | (System) | New version available: draft-ietf-pkix-scvp-15.txt |
|
2004-04-08
|
14 | (System) | New version available: draft-ietf-pkix-scvp-14.txt |
|
2003-10-27
|
13 | (System) | New version available: draft-ietf-pkix-scvp-13.txt |
|
2003-06-30
|
12 | (System) | New version available: draft-ietf-pkix-scvp-12.txt |
|
2003-01-06
|
11 | (System) | New version available: draft-ietf-pkix-scvp-11.txt |
|
2002-11-06
|
10 | (System) | New version available: draft-ietf-pkix-scvp-10.txt |
|
2002-07-29
|
09 | (System) | New version available: draft-ietf-pkix-scvp-09.txt |
|
2002-03-06
|
08 | (System) | New version available: draft-ietf-pkix-scvp-08.txt |
|
2002-02-01
|
07 | (System) | New version available: draft-ietf-pkix-scvp-07.txt |
|
2001-07-19
|
06 | (System) | New version available: draft-ietf-pkix-scvp-06.txt |
|
2001-06-01
|
05 | (System) | New version available: draft-ietf-pkix-scvp-05.txt |
|
2000-11-28
|
04 | (System) | New version available: draft-ietf-pkix-scvp-04.txt |
|
2000-07-13
|
03 | (System) | New version available: draft-ietf-pkix-scvp-03.txt |
|
2000-03-10
|
02 | (System) | New version available: draft-ietf-pkix-scvp-02.txt |
|
1999-08-10
|
01 | (System) | New version available: draft-ietf-pkix-scvp-01.txt |
|
1999-06-25
|
00 | (System) | New version available: draft-ietf-pkix-scvp-00.txt |