[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 5055

Internet Draft                                       Ambarish Malpani
draft-ietf-pkix-scvp-00.txt                                  ValiCert
June 25, 1999                                            Paul Hoffman
Expires in six months                                  VPN Consortium

          Simple Certificate Validation Protocol (SCVP)

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


Abstract

The SCVP protocol allows a client to offload certificate handling to a
server. The server can give a variety of valuable information about the
certificate, such as whether or not it is valid, what the public key
and subject of the certificate is, and so on.


1. Introduction

Certificate validation is a difficult problem to solve. If certificate
handling is to be widely deployed in applications, the amount of
processing an application needs to perform before it can accept a
certificate must be greatly reduced. There are a variety of
applications that can use public key certificates but are burdened by
the overhead of parsing and validating the certificates when all the
application really wants is the public key from the certificate and a
determination of whether or not the certificate may be used for a
particular purpose.

The goals of SCVP are:
- Make it easier for  applications to deploy PKI based systems
- Enable the PKI to be used on low-end devices such as telephones
- Allow centralization of administering PKI policies

1.1 Terminology

Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT
are used in capital letters. This  conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
make the intent of standards track documents as clear as possible. The
same key words are used in this document to help implementors achieve
interoperability.

In sections 3 and 4, values are given in decimal notation. In section
5, values are given in hexadecimal notation. Hexadecimal values are
indicated as "xNN" or "xNNNN". For example, xA0B1 corresponds to the
octet xA0 followed by the octet xB1.


2. Protocol

The SCVP protocol uses a simple request-response model. That is, a SCVP
client creates a single request and sends it to the server; the server
creates a single response and sends it to the client. Typical use of
SVCP is expected to be over HTTP, and possibly email. This document
registers MIME types for SVCP requests and responses.

There are two syntaxes for SCVP: a "tiny" syntax designed for clients
that do not have ASN.1 parsers, and an ASN.1 syntax for clients that
prefer ASN.1 formats. The semantics are identical for each format; the
only difference is the bits on the wire for the requests and replies.
The semantics are described in sections 3 (requests) and 4 (responses).
The syntaxes are described in sections 5 (tiny syntax) and 6 (ASN.1).

The primary reason for the SCVP protocol to have two different syntaxes
is that SCVP is aimed at two different markets that have different code
bases. Manufacturers of mall devices such as cell phones may not want
to incur the large overhead of an ASN.1 encoder/decoder in their devices and
might thus not use SCVP. On the other hand, developers of programs that
already have ASN.1 compilers built into them may not want to add the
overhead of a second syntax if they can just use ASN.1.

It is expected that individual SCVP clients will only use one of the
two syntaxes, but that most or all SCVP servers will be able to handle
both. Because of the nature of the checking that they are doing, SCVP
servers must be able to process ASN.1; the additional overhead of
parsing queries and forming responses using the tiny syntax should be
relatively small.

3. Requests

A SCVP client's request to the server MUST be a single FullRequest
item. The FullRequest item contains the entire request. A FullRequest
item is carried in an application/scvp-request MIME body part.

3.1 FullRequest

The FullRequest item encapsulates the client's request. The FullRequest
item contains a Version item, zero or more Extension items, a
CertsQuery items, an optional RequestNonce item, an optional
RequestHash item, and an optional RequestSignature item.

3.2 Version

The Version item tells the version of SCVP used in a request or a
response. The value of the Version item for this specification is 1.

3.3 Extension

The Extension item specifies an extension to the SCVP protocol, for
example to request additional information about the certificate(s) in
the CertsQuery. The Extension contains an ExtensionID item, an
ExtensionCritical item, and an ExtensionValue item.

3.4 ExtensionID

The ExtensionID item is an identifier for the extension. It
contains the OID of the extension.

3.5 ExtensionCritical

The ExtensionCritical item tells whether the extension is
critical. The values for the item are:

0  Not critical
1  Critical

3.6 ExtensionValue

The ExtensionParameters item gives parameters for an extension.
It contains a sequence of octets.

3.7 CertsQuery

The CertsQuery item specifies a request for information on one or more
certificate. A CertsQuery contains a CertBundle item, a TypesOfCheck
item, and a WantBack item. A CertsQuery item can also contain zero or
more Extension items, and zero or one of each of the following items:
IntermediateCerts, TrustedRoots, UsageID, and ConfigurationIdentifier.

The CertBundle item tells the server the certificate(s) the client
wants a reply for; the certificate(s) in the CertBundle item in the
CertsQuery item MUST be FullCert items. The TypesOfCheck item tells the
server what types of checking it should do on the certificate(s), and
the WantBack item tells the server what the client wants to know about
the certificate(s). The optional IntermediateCerts, TrustedRoots,
UsageID, and ConfigurationIdentifier items tell the server how to
process the request. If there is more than one certificate in the
CertBundle item, the other items all apply to every certificate in the
CertBundle item.

3.8 CertBundle

The CertBundle item contains one or more certificates, represented
as FullCert items and/or CertID items. The order of the
certificate(s) in the bundle is not important. The items that use
CertBundle items specify the types of certificates that can be in
the CertBundle items.

3.9 FullCert

The FullCert item contains a complete certificate. The FullCert item
contains an identifier for the type of certificate and the octets of
the certificate itself. The types of certificates are:

0  PKIX [PKIX]
1  OpenPGP [OpenPGP]

3.10 CertID

The CertID item contains the hash of a certificate. The CertID item
has an identifier for the type of certificate and the SHA-1 [SHA-1]
hash of the octets of the certificate itself. The types of certificates
are:

0  PKIX [PKIX]
1  OpenPGP [OpenPGP]

3.11 TypesOfCheck

The TypesOfCheck item describes the kind of checking that the client
wants the server to do on the certificate(s) in the CertsQuery item. If
the TypesOfCheck item is given in a request, it can contain one or more
types of checks. For each type of check specified in the request, the
server MUST return information on what it found during the check. The
types of checks are:

0  Path validation to a trusted root
1  Revocation status

3.12 WantBack

The WantBack item describes the kind of information the client wants
from the server for the certificate(s) in the CertsQuery item. If the
WantBack item is given in a request, it can contain one or more types
of information. For each type of information specified in the request,
the server MUST return information on what it found during the check.
The types of information that can be requested are:

0  Public key of the subject of the certificate
1  Subject of the certificate
2  Certificate chain used to validate the certificate
3  Proof of revocation status

For example, a request might include a TypesOfCheck item that does not
specify path validation, and include a WantBack item that specifies the
certificate chain used to validate. The response would not include a
status for the validation, but would include a certificate chain that
the server thinks might validate. This set of options might be used by
a client that wants to do its own path validation.

3.13 IntermediateCerts

The IntermediateCerts item specifies to the server the intermediate
certificates that the server MAY use when forming a certificate chain
in addition to any other certificates that the server knows of. The
IntermediateCerts item contains a CertBundle item; the certificate(s)
in the CertBundle item MUST be FullCert items. The certificates in the
IntermediateCerts MUST NOT be self-signed certificates.

3.14 TrustedRoots

The TrustedRoots item specifies to the server the root certificates
that the server MUST use. If a TrustedRoots item is included in a
CertsQuery item, the server MUST NOT use any roots other than the
certificates in the TrustedRoots item when forming a certificate chain
for validation. The TrustedRoots item contains a CertBundle item. the
certificate(s) in the TrustedRoots MAY be FullCert items or CertID
items.

3.15 UsageID

The UsageID item specifies to the server the policy ID that the server
MUST use when forming a certificate chain. The UsageID item contains
the OID of the policy.

3.16 ConfigurationIdentifier

The ConfigurationIdentifier item tells the server the SCVP options
that the client wants the server to use. The client can use this option
instead of specifying other SCVP configuration such as UsageID, TrustedRoots,
and so on. The value of this item is determined by private agreement
between the client and the server and is not specified in this
document. For example, the value might be the hash of some set of options,
or it might be a short identifier for a common set of options. Further,
the server might want to have identifiers that indicate that some
settings are used in addition to others given in the request; in this
way, the configuration identifier might be a shorthand for some
SCVP options.

3.17 RequestNonce

The RequestNonce item is an identifier generated by the client for the
request; the server MUST return the same RequestNonce in the signed part
of the server's response. The RequestNonce item is simply a sequence of
octets. The client SHOULD include a RequestNonce item in every request
to prevent an attacker acting as a man-in-the-middle from replaying old
responses from the server. The value of the nonce SHOULD change with
every request sent from the client.

3.18 RequestHash

The RequestHash item is the SHA-1 hash of all the items in the
FullRequest other than the RequestHash item and the RequestSignature
items. The RequestHash item serves many purposes:
- It helps the server check if there was accidental modification of a
request in transit if the request was not signed
- It helps a client using unsigned requests know that the request was
not maliciously modified when the client gets the response back
- It allows the client to associate a response with a request when
using connectionless protocols

The server MUST check the hash to verify that the request was not
modified in transit, and MUST return the RequestHash item in the
response.

3.19 RequestSignature

The RequestSignature item is the signature of all the items in the
FullRequest item other than the RequestSignature item itself. The
RequestSignature item contains a Name item that is the name of the
client, a SigningAlgorithm item that is the algorithm used to sign the
request, and a SignatureBits item that is the signature itself. The
RequestSignature item may contain a KeyID item that identifies the
signing key. The RequestSignature item may also contain an optional
CertBundle that represents a chain of certs for the key used to sign
the request.

Requests SHOULD include a RequestSignature item. The only situation in
which a request need not be signed is when the request is done over an
authenticated channel, such as through a connection secured with IPsec
or through signed email messages.

3.20 Name

The Name item holds the name of a signer. It is used to associate a key
with the request.

3.21 SigningAlgorithm

The SigningAlgorithm identifies the algorithm used to sign a request or
response. The SigningAlgorithm item contains the OID of the algorithm
and any necessary parameters for the algorithm.

3.22 SignatureBits

The SignatureBits item holds the octets of a signature. The structure
of the SignatureBits item is determined by the value of the
SigningAlgorithm item.

3.23 KeyID

The KeyID item contains the hash of a public key. The KeyID item has
the SHA-1 hash of the octets of the key itself. [[[What bits are to be hashed?]]]


4. Responses

A SCVP server's response to the client MUST be a single FullResponse
item. The FullResponse item contains the entire response. A
FullResponse item is carried in an application/scvp-response MIME body
part.

4.1 FullResponse

The FullResponse item encapsulates the server's response. The item
contains a Version item, a ProducedAt item, a ResponseStatus item,
optional Extension items, optional CertReply items, an optional
RequestNonce item, an optional RequestHash item, and an optional
ResponseSignature item. The FullResponse item MUST contain exactly one
CertReply item for each certificate requested in the request. The
RequestNonce item MUST be included if the request had a RequestNonce
item. The RequestHash item MUST be included if the request had a
RequestHash item.

4.2 ProducedAt

The ProducedAt item tells the time at which the whole response was
produced. The ProducedAt item represents the date at Greenwich Mean
Time.

4.3 ResponseStatus

The ResponseStatus item gives status information to the client about
its request. The ResponseStatus item has a main status code, a
secondary status code, and an optional string that is a sequence of
characters from the ISO/IEC 10646-1 character set encoded with the
UTF-8 transformation format defined in [UTF8].

The optional string may be used to transmit status information, but it
is optional. The client MAY choose to display the string to the client.
However, because there is no way to know the languages understood by
the user, the string may be of little or no use to them.

The values for the main status code are based loosely on those in SMTP.
They are:

0 - positive completion
1 - transient negative completion
2 - permanent negative completion

After validating the signature on a response, a client MAY use just the
main status code to decide how to display any results of the request to
the user who made the request.

The complete list of status codes for the ResponseStatus item
(displayed as main code, secondary code, and meaning) is:

0 0  The request was fully processable
0 1  The request included unrecognized items; continuing

1 0  Too busy; try again whenever you feel like it
1 1  Too busy; try again later than 10 seconds from now
1 2  Too busy; try again later than 60 seconds from now

2 0  The structure of the request was wrong
2 1  The version of request is not supported by this server
2 2  The request included unrecognized items; aborting
2 3  The key given in the RequestSignature is not recognized
2 4  The signature did not match the body of the request
2 5  The hash in the RequestHash did not compute
2 6  The request was not authorized

4.4 CertReply

The CertReply item tells the client about a single certificate from the
request. The CertReply item contains a CertID item identifying the
certificate, a ReplyStatus item, and a ThisUpdate item. There may be
zero or more Extension items. There may also be the following optional
items: ValidationStatus, RevocationStatus, PublicKey, CertSubject,
ValidationChain, and RevocationProof.

The presence or absence of the ValidationStatus, RevocationStatus,
PublicKey, CertSubject, ValidationChain, and RevocationProof items in
the CertReply item is controlled by the TypesOfCheck and WantBack items
in the request. A server MUST include one of the above items for each
related item requested in the TypesOfCheck and WantBack items.

4.5 ReplyStatus

The ReplyStatus item gives status information to the client about the
request for the specific certificate. Note that the ResponseStatus item
is different than the ReplyStatus item. The ResponseStatus item is the
status of the whole request, while the ReplyStatus item is the status
for the individual certificate.

The complete list of status codes for the ReplyStatus item is:

0  Success: a definitive answer follows
1  Failure: the certificate type is not recognized
2  Failure: an item wanted in TypesOfCheck is not recognized
3  Failure: an item wanted in WantBack is not recognized
4  Failure: the certificate was malformed
5  Failure: the mandatory UsageID is not recognized
6  Failure: the ConfigurationIdentifier is not recognized
7  Failure: unauthorized request

Status code 4 is used to tell the client that the request was properly
formed but the certificate in question was not. This is useful to
clients that cannot parse a certificate.

4.6 ThisUpdate

The ThisUpdate item tells the time at which the information in the
CertReply was produced. The ThisUpdate item represents the date at
Greenwich Mean Time.

4.7 ValidationStatus

The ValidationStatus item tells the client whether or not the
certificate is valid based on chaining to a trusted root key. The
values for ValidationStatus are:

0  Valid
1  Not valid
2  Temporarily unknown
3  Unknown

4.8 RevocationStatus

The RevocationStatus item tells the client whether or not the
certificate has been revoked. The values for RevocationStatus are:

0  Good
1  Revoked
2  Temporarily unknown
3  Unknown

[[[Should we add a field to specify the reasons for revocation?]]]

4.9 PublicKey

The PublicKey item tells the client the public key in the certificate.
[[[More is needed here about the format for the reply. Is it just the
bits from the certificate, or is there some structure with the type of
key returned? What about OpenPGP keys?]]]

4.10 CertSubject

The CertSubject item tells the client the subject of the certificate.
[[[Much more is needed here about the format for the reply. Is it a
sequence of bits, or does it have structure? What about subjectAltName?
What about OpenPGP subjects?]]]

4.11 ValidationChain

The ValidationChain item tells the client the chain of certificates
that was used to validate the certificate. The ValidationChain item
contains a CertBundle item. The certificate(s) in the CertBundle item
MAY be either FullCert items or CertID items.

4.12 RevocationProof

The RevocationProof item gives the client the proof that the server
used to check revocation. This can be either the full OCSP response
that the server used, or the CRL(s) used to determine the revocation
information. [[[More is needed here, such as a structure to say what
kind of item is included.]]]

4.13 ResponseSignature

The ResponseSignature item is the signature of all the items in the
FullResponse item other than the ResponseSignature item itself. The
ResponseSignature item contains a Name item that is the name of the
server, a SigningAlgorithm item that is the algorithm used to sign the
response, and a SignatureBits item that is the signature itself. The
ResponseSignature item may contain a KeyID item that identifies the
signing key. The ResponseSignature item may also contain an optional
CertBundle that represents a chain of certs for the key used to sign
the response.

Responses SHOULD include a ResponseSignature item. A server might not
sign a reponse if the response only contains an error code in the
ResponseStatus. Another situation in which a response need not be
signed is when the response is done over an authenticated channel, such
as through a connection secured with IPsec or through signed email
messages.


5. Tiny Syntax for SCVP

Tiny syntax SCVP requests and responses have a simple format. The
format is optimized for simple processing in small clients. An explicit
design goal of the tiny syntax SCVP is to greatly reduce code overhead
by not requiring clients to have to use a generalized ASN.1 processor
for creating requests and understanding responses.

The basic unit of the tiny syntax is the item. A tiny syntax item
consists of exactly three parts:
 - a two-octet tag
 - a four-octet length
 - content whose length and structure are defined by the tag
Each of the three parts of an are in network byte order, as is the
entire item.

The tag values are given in this section. The length is the number of
octets in the content of the item. Some tags define fixed-length
content, while other tags define variable-length content. The structure
of the content of each item is defined in the item; there is no data
typing in the tiny syntax.

A program parsing a request or response can easily skip over items
whose tags it doesn't recognize by reading the tag, reading the length,
and skipping over the number of octets given in the length to get to
the beginning of the next item. Because of this, no data typing is
needed.

5.1 Tiny syntax of items

The following table lists the items from sections 3 and 4, and gives
the tag values and structure of each.

Item                       Tag    Structure

FullRequest                x0000  A Version item, followed by zero or
                                  more Extension items, followed by a
                                  CertsQuery items, followed by zero or
                                  one RequestNonce item, followed by
                                  zero or one RequestHash item,
                                  followed by zero or one
                                  RequestSignature item.

Version                    x0001  One octet.

Extension                  x001C  An ExtesnionID item, followed by an
                                  ExtensionCritical item, followed by
                                  an ExtensionParameters item.

ExtensionID                x001D  A sequence of octets.

ExtensionCritical          x001E  One octet.

ExtensionParameters        x001F  A sequence of octets.

CertsQuery                 x0002  A CertBundle item, followed by a
                                  TypesOfCheck item, followed by a
                                  WantBack item, followed by zero or
                                  more Extension items, followed by an
                                  unordered set of zero or one of each
                                  of the following items:
                                  IntermediateCerts, TrustedRoots,
                                  UsageID, and ConfigurationIdentifier.

CertBundle                 x0003  An unordered set of one or more of
                                  certificates.

FullCert                   x0004  A single octet representing the type
                                  of certificate, followed by the
                                  octets that make up the certificate.

CertID                     x0005  A single octet representing the type
                                  of certificate, followed by the 20
                                  octets that make up the hash of the
                                  certificate.

TypesOfCheck               x0006  One octet for each type of check.

WantBack                   x0007  One octet for each item wanted back.

IntermediateCerts          x0008  A CertBundle item.

TrustedRoots               x0009  A CertBundle item.

UsageID                    x000A  A sequence of octets.

ConfigurationIdentifier    x000B  A sequence of octets.

RequestNonce               x000C  A sequence of octets.

RequestHash                x000D  The 20 octets that make up the hash.

RequestSignature           x000E  A Name item, followed by a
                                  SigningAlgorithm item, followed by a
                                  SignatureBits item, followed by
                                  zero or one KeyID item, followed by
                                  zero or one CertBundle item.

Name                       x0020  A sequence of octets.

SigningAlgorithm           x0021  A sequence of octets.

SignatureBits              x0022  A sequence of octets.

KeyID                      x0023  The 20 octets that make up the hash.

FullResponse               x0010  A Version item, followed by a
                                  ProducedAt item, followed by a
                                  ResponseStatus items, followed by
                                  zero or more Extension items,
                                  followed by zero or more CertReply
                                  items, followed by zero or one
                                  RequestNonce items, followed by zero
                                  or one ResponseSignature items.

ProducedAt                 x0024  14 octets representing the date in
                                  YYYYMMDDHHMMSS format.

ResponseStatus             x0011  One octet for the main status code,
                                  followed by one octet for the
                                  secondary status code, followed by
                                  zero or more octets that make up the
                                  string of characters.

CertReply                  x0012  One CertID item, followed by a
                                  ReplyStatus item, followed by a
                                  ThisUpdate item, followed by zero or
                                  more Extension items, followed by
                                  zero or one of each of the following
                                  items: ValidationStatus,
                                  RevocationStatus, PublicKey,
                                  CertSubject, ValidationChain, and
                                  RevocationProof.

ReplyStatus                x0013  A single octet.

ThisUpdate                 x0014  14 octets representing the date in
                                  YYYYMMDDHHMMSS format.

ValidationStatus           x0015  A single octet.

RevocationStatus           x0016  A single octet.

PublicKey                  x0017  A sequence of octets.

CertSubject                x0018  A sequence of octets.

ValidationChain            x0019  A CertBundle item.

RevocationProof            x001A  A sequence of octets.

ResponseSignature          x001B  A Name item, followed by a
                                  SigningAlgorithm item, followed by a
                                  SignatureBits item, followed by
                                  zero or one KeyID item, followed by
                                  zero or one CertBundle item.


5.2 Examples of tiny syntax

The following is an example of a simple request. The client is asking
the server for validation and revocation information on a single
certificate, as well as for the public key and the subject name that is
contained in the certificate.

The structure for this request can be viewed as:

FullRequest (
    Version ( x01 )
    CertsQuery (
        CertBundle (
            FullCert ( x00 <octets of cert> )
         )
        TypesOfCheck ( x00 x01 )
        WantBack ( x00 x01 )
        )
    )
    RequestNonce ( <octets of nonce> )
    RequestHash ( <octets of hash> )
    RequestSignature (
        Name ( <octets of name> )
        SigningAlgorithm ( <OID> )
        SignatureBits ( <octets of signature> )
    )
)

The actual request would be as follows (note that some of the values
here are made up):

0000 0000 0157                            FullRequest tag, length
0001 0000 0001                            Version tag, length
01                                        Version number
0002 0000 00BF                            CertsQuery tag, length
0003 0000 00A9                            CertBundle tag, length
0004 0000 00A3                            FullCert tag, length
00                                        PKIX cert
66A2 920B FF24 8A90 017D 3282 421A B230   Contents of cert
0000 008B 4308 A3B8 FFC7 0530 0306 0800     ...
. . .
0006 0000 0002                            TypesOfCheck tag, length
00                                        Want path validation
01                                        Want revocation status
0007 0000 0002                            WantBack tag, length
00                                        Want public key
01                                        Want subject
000C 0000 0008                            RequestNonce tag, length
8BFA 8D50 FF80 3819                       The nonce
000D 0000 0014                            RequestHash tag, length
C074 FEFF 0950 E885 A1C0 1006 0885 FF83   The hash
1B42                                       ...
000E 0000 005D                            RequestSignature tag, len.
0020 0000 0004                            Name tag, len.
4269 6C6C                                 The name
0021 0000 0007                            SigningAlgorithm tag, len.
2A86 48CE 3804 01                         The OID
0022 0000 0040                            SignatureBits, len.
A1C0 1006 0885 C074 0950 E885 FEFF FF83   Contents of the signature
C404 6880 AC05 08E8 78FE FFFF E807 FAFF
. . .

The following is an example of the reply to the preceding simple
request. The server says that the cert is valid, not revoked, and gives
the subject name and the public key from the certificate.

The structure for this response can be viewed as:

FullResponse (
    Version ( x01 )
    ProducedAt ( <date> )
    ResponseStatus ( <OK status> <nice words> )
    CertReply (
        CertID ( <the cert> )
        ReplyStatus ( <OK status> )
        ThisUpdate ( <date> )
        RevocationStatus ( <not revoked> )
        ValidationStatus ( <is valid> )
        CertSubject ( <the subject> )
        PublicKey ( <the key> )
    )
    RequestNonce( <octets of nonce> )
    ResponseSignature(
        Name ( <octets of name> )
        SigningAlgorithm ( <OID> )
        SignatureBits ( <octets of signature> )
    )

)

The actual reply would be as follows (note that some of the values here
are made up):

0010 0000 0319                            FullResponse tag, length
0001 0000 0001                            Version tag, length
01
00XX 0000 000E                            ProducedAt tag, length
3139 3939 3036 3133 3037 3532 3231        Date: 19990613075221
0011 0000 000C                            ResponseStatus, length
00                                        OK main status
00                                        OK secondary status
4E6F 2070 726F 626C 656D                  Some text
0012 0000 0270                            CertReply tag, length
0005 0000 0015                            CertID tag, length
00                                        PKIX cert
A255 920B FF24 8A90 017D 3282 421A B230   Hash of cert
31ED EB00                                  ...
0013 0000 0001                            ReplyStatus tag, length
00                                        OK status
0014 0000 000E                            ThisUpdate tag, length
3139 3939 3036 3133 3037 3532 3230        Date: 19990613075220
0016 0000 0001                            RevocationStatus tag, len.
00                                        OK
0015 0000 0001                            ValidationStatus tag, len.
00                                        OK
0018 0000 0020                            CertSubject tag, length
83C3 0483 3B00 75F4 8B5D FCC9 C38D 7600   The subject
5589 E5C9 C390 9090 5589 E5FF 750C FF75
000C 0000 0008                            RequestNonce tag, length
0017 0000 0200                            PublicKey tag, length
50E8 AEFE FFFF 89F6 5589 E553 BB2C 0106   512-bit key
0883 3D2C 0106 0800 740E 89F6 8B03 FFD0      ...
...
8BFA 8D50 FF80 3819                       The nonce
001B 0000 005C                            ResponseSignature, length
0020 0000 0003                            Name tag, len.
4D6F 6D                                   The name
0021 0000 0007                            SigningAlgorithm tag, len.
2A86 48CE 3804 01                         The OID
0022 0000 0040                            SignatureBits, len.
40FC FFFF 6A01 6A02 E837 FCFF FFE8 6AE9   Contents of the signature
0000 31C0 C9C3 89F6 5589 E581 EC5C 3C01    ...
. . .

6. ASN.1 Syntax for SCVP


SCVP DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS
    ; -- TO BE DONE

FullRequest ::= SEQUENCE {
    version          Version,
    extensions       [0] Extensions OPTIONAL,
    certsQuery           CertsQuery,
    requestNonce     [1] RequestNonce OPTIONAL,
    requestHash      [2] RequestHash OPTIONAL,
    requestSignature [3] Signature OPTIONAL
}

Version ::= INTEGER

RequestNonce ::= OCTET STRING

RequestHash ::= OCTET STRING

CertsQuery ::= SEQUENCE {
    certBundle        CertBundle,
    typesOfCheck      TypesOfCheck,
    wantBack          WantBack,
    extensions        [0] Extensions OPTIONAL,
    intermediateCerts [1] IntermediateCerts OPTIONAL,
    trustedRoots      [2] TrustedRoots OPTIONAL,
    usageID           [3] OBJECT IDENTIFIER OPTIONAL,
    configurationIdentifier [4] OBJECT IDENTIFIER OPTIONAL
}

CertBundle ::= SEQUENCE OF CertItem

CertItem ::= CHOICE {
    fullCert      [0] Cert,
    certID        [1] CertID
}

Cert ::= CHOICE {
    pkixCert        [0] Certificate,
    pgpCert         [1] OCTET STRING
}

CertID ::= CHOICE {
    pkixCert       [0] OCTET STRING,
    pgpCert        [1] OCTET STRING
}

TypesOfCheck ::= BIT STRING {
    pathValidation      (0),
    revocationStatus    (1)
}

WantBack ::= BIT STRING {
    subjectPubKey    (0),
    subjectName      (1),
    certChain        (2),
    revocationProof  (3)
}

IntermediateCerts ::= CertBundle

TrustedRoots ::= CertBundle

Signature ::= SEQUENCE {
    signerName               Name,
    keyID                [0] KeyID OPTIONAL,
    signatureAlgorithm       AlgorithmIdentifier,
    signatureBits            BIT STRING,
    certs                [1] CertBundle OPTIONAL
}

KeyID ::= OCTET STRING

FullResponse ::= SEQUENCE {
    version               Version,
    producedAt            GeneralizedTime,
    responseStatus        ResponseStatus,
    extensions        [0] Extensions OPTIONAL,
    certReplies       [1] SEQUENCE OF CertReply OPTIONAL,
    requestNonce      [2] RequestNonce OPTIONAL,
    requestHash       [3] RequestHash OPTIONAL,
    responseSignature [4] Signature OPTIONAL
}

ResponseStatus ::= SEQUENCE {
    mainStatus          INTEGER,
    secondaryStatus     INTEGER,
    errorMessage    [0] UTF8String OPTIONAL
}

CertReply ::= SEQUENCE {
    certID               CertID,
    replyStatus          ReplyStatus,
    thisUpdate           GeneralizedTime,
    singleExtensions [0] Extensions OPTIONAL,
    validationStatus [1] ValidationStatus OPTIONAL,
    revocationStatus [2] RevocationStatus OPTIONAL,
    subjectPublicKey [3] SubjectPublicKeyInfo OPTIONAL, -- OK for PGP?
    subjectName      [4] Name OPTIONAL,                 -- OK for PGP?
    validationChain  [5] SEQUENCE OF CertItem OPTIONAL,
    revocationProofs [6] SEQUENCE OF RevocationProof OPTIONAL
}

ReplyStatus ::= ENUMERATED {
    success                  (0),
    certTypeUnrecognized     (1),
    typeOfCheckUnrecognized  (2),
    wantBackUnrecognized     (3),
    certMalformed            (4),
    usageIDUnrecognized      (5),
    configInfoUnrecognized   (6),
    unauthorizedRequest      (7)
}

ValidationStatus ::= ENUMERATED {
    valid                    (0),
    notValid                 (1),
    temporarilyUnknown       (2),
    unknown                  (3)
}

RevocationStatus ::= ENUMERATED {
    good                     (0),
    revoked                  (1),
    temporarilyUnknown       (2),
    unknown                  (3)
}

RevocationProof ::= SEQUENCE {
    type    OBJECT IDENTIFIER,
    proof   OCTET STRING -- DER encoding of proof defined by type
}

END


7. Security Considerations

The current draft doesn't specify how the security algorithms will be
used, and thus doesn't give enough detail to analyze the security
considerations of the specification.

If a request has neither a RequestHash item nor a RequestSignature item
and the request contains certificates that are not being validated, a
man-in-the-middle attack could change the values of the certificates
and cause the server to give different answers to a request. The same
attack is available if the server does not check the hash or the
signature on the request.

If a response does not have a ResponseSignature item and is transmitted
over an insecure channel, a man-in-the-middle attack could fool the
client into believing modified responses from the server, or responses
to questions the client did not ask. The same attacks are available if
the client does not check the signature on the response.

If the client does not include a RequestNonce item, or if the client
does not check that the RequestNonce in the reply matches that in the
request, an attacker can replay previous responses from the server.

If the server does not require some sort of authorization (such as
signed requests), an attacker can get the server to reply to arbitrary
requests. Such responses may give the attacker information about
weaknesses in the server or about the timeliness of the server's
checking. This information may be valuable for a future attack.


A. References

[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119.

[OpenPGP] "OpenPGP Message Format", RFC 2440.

[PKIX] "PKIX Certificate and CRL Profile", RFC 2459.

[SHA-1] "Secure Hash Standard", NIST FIPS publication 180-1,
April 1995.

[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.


B. Acknowledgments

Graham Klyne provided suggestions to a different draft that are reflected
in this one.


C. Changes Between Versions of This Document

None yet.


D. MIME Registrations

D.1 Registration for application/scvp-request [TBD]

D.2 Registration for application/scvp-response [TBD]


E. Author Contact Information

Ambarish Malpani
ValiCert
1215 Terra Bella Ave.
Mountain View, CA 94043-1833
ambarish@valicert.com

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA  95060 USA
paul.hoffman@vpnc.org

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/