Skip to main content

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
[Ballot comment]
I'm concerned this may not comply with BCP 56 (RFC 3205).  I need to read the spec in more depth to …
[Ballot comment]
I'm concerned this may not comply with BCP 56 (RFC 3205).  I need to read the spec in more depth to make sure.  But consider this advance warning that I may issue a DISCUSS on that topic after I've evaluated this.
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