One document matched: draft-ietf-pkix-scvp-00.txt
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| PAFTECH AB 2003-2026 | 2026-04-23 00:36:23 |