< draft-ietf-pkix-scvp-03.txt		draft-ietf-pkix-scvp-04.txt >
	Internet Draft Ambarish Malpani		Internet Draft Ambarish Malpani
	draft-ietf-pkix-scvp-03.txt ValiCert		draft-ietf-pkix-scvp-04.txt ValiCert
	June 12, 2000 Paul Hoffman		November 2000 Paul Hoffman
	Expires in six months VPN Consortium		Expires in six months VPN Consortium
			Russ Housley
			SPYRUS
	Simple Certificate Validation Protocol (SCVP)		Simple Certificate Validation Protocol (SCVP)
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.		provisions of Section 10 of RFC 2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	skipping to change at line 54 ¶		skipping to change at line 56 ¶
	the overhead of validating the certificates when all the application		the overhead of validating the certificates when all the application
	really wants is the public key and name from the certificate, and a		really wants is the public key and name from the certificate, and a
	determination of whether or not the certificate may be used for a		determination of whether or not the certificate may be used for a
	particular purpose. There are other applications that can perform		particular purpose. There are other applications that can perform
	certificate path validation but have no reliable method of obtaining a		certificate path validation but have no reliable method of obtaining a
	current chain to a trusted certificate.		current chain to a trusted certificate.
	1.1 SCVP overview and requirements		1.1 SCVP overview and requirements
	The primary goals of SCVP are to make it easier for applications to		The primary goals of SCVP are to make it easier for applications to
	deploy systems using a PKI and to allow centralization of administering		deploy systems using a PKI and to allow central administration of
	PKI policies. Parts of SCVP can be used by clients that do much of the		PKI policies. Parts of SCVP can be used by clients that do much of the
	PKI processing themselves and simply want a useful but untrusted server		PKI processing themselves and simply want a useful but untrusted server
	that will collect information for them. Other parts can be used by		that will collect information for them. Other parts can be used by
	clients that have complete trust in the server to both offload the work		clients that have complete trust in the server to both offload the work
	of certificate validation and to ensure that policies are enforced in a		of certificate validation and to ensure that policies are enforced in a
	consistent fashion across an enterprise.		consistent fashion across an enterprise.
	Untrusted SCVP servers can give client the certificate chains needed		Untrusted SCVP servers can give clients the certificate chains needed
	for path validation. They can also give clients revocation information		for path validation. They can also give clients revocation information
	such as CRLs and OCSP responses that the client can use in the client's		such as CRLs and OCSP responses that the client can use in the client's
	path validation. These services can be valuable to client systems that		path validation. These services can be valuable to client systems that
	do not include the protocols needed to find and download all of the		do not include the protocols needed to find and download all of the
	intermediate certificates, CRLs, and OCSP responses needed for the		intermediate certificates, CRLs, and OCSP responses needed for the
	client to perform complete path validation.		client to perform complete path validation.
	Trusted SCVP servers can perform full certificate validation for the		Trusted SCVP servers can perform full certificate validation for the
	client. If a client uses these services, it inherently trusts the SCVP		client. If a client uses these services, it inherently trusts the SCVP
	server as much as it would its own path validation software (if it		server as much as it would its own path validation software (if it
	skipping to change at line 108 ¶		skipping to change at line 110 ¶
	the server "don't give me an answer unless you understand this		the server "don't give me an answer unless you understand this
	extension", and marking a response extension as critical says "don't		extension", and marking a response extension as critical says "don't
	use this response unless you understand this extension". Without the		use this response unless you understand this extension". Without the
	critical bit in the extensions, either the semantics of extensions		critical bit in the extensions, either the semantics of extensions
	would have to be changed to essentially say "all extensions are		would have to be changed to essentially say "all extensions are
	critical" (which is overkill for some extensions that might really be		critical" (which is overkill for some extensions that might really be
	optional), or the semantics would have to be changed to say "you can		optional), or the semantics would have to be changed to say "you can
	never rely on the other party understanding an extension", which would		never rely on the other party understanding an extension", which would
	limit the usefulness of some extensions.		limit the usefulness of some extensions.
	- All responses are signed. There may be cases where the server		- Need to deal with certificate URLs, where a client doesn't have the
	doesn't want to sign the responses, such as on messages that		certificate, but just a pointer to where the certificate is
	are only error responses, or where the message is travelling over a		located. Should we even try and deal with this?
	medium that is already known to be secure.
			- Is there any value to an "unvalidated path"?
			- Need to specify how client asks for and gets back parsed pieces of a
			certificate. Is this important? What fields do people want?
			- Should CMS (RFC 2630) be used for signed ASN.1 messages?
			- Should SCVP support validation of attribute certificates?
	2. Protocol		2. Protocol
	The SCVP protocol uses a simple request-response model. That is, a SCVP		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		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		creates a single response and sends it to the client. Typical use of
	SCVP is expected to be over HTTP, and possibly email. This document		SCVP is expected to be over HTTP, and possibly email. This document
	registers MIME types for SCVP requests and responses.		registers MIME types for SCVP requests and responses.
	3. Requests		3. Requests
	skipping to change at line 134 ¶		skipping to change at line 144 ¶
	item. The FullRequest item contains the entire request. A FullRequest		item. The FullRequest item contains the entire request. A FullRequest
	item is carried in an application/scvp-request MIME body part.		item is carried in an application/scvp-request MIME body part.
	3.1 FullRequest		3.1 FullRequest
	The FullRequest item encapsulates the client's request. The FullRequest		The FullRequest item encapsulates the client's request. The FullRequest
	item contains a PSRequest item, and an optional RequestSignature item.		item contains a PSRequest item, and an optional RequestSignature item.
	3.2 PSRequest		3.2 PSRequest
	The PSRequest item contains the part of the client's request.		The PSRequest item contains the part of the client's request. The
	The PSRequest item		PSRequest item contains a Version item, a Query item, a TypesOfCheck
	contains a Version item, a Query item, a TypesOfCheck item, and a		item, and a WantBack item. It can also contain an optional
	WantBack item. It can also contain an optional RequestNonce item and		RequestNonce item and an optional ReqExtensions item. (The "PS" in
	an optional ReqExtensions item. (The "PS" in PSRequest means "possibly		PSRequest means "possibly signed".)
	signed".)
	A signed request can be used to authenticate the client to the		A signed request can be used to authenticate the client to the
	server and for non-repudiation of the client's request, such as for		server and for non-repudiation of the client's request, such as for
	accounting purposes. A server might require all requests to be signed		accounting purposes. A server might require all requests to be signed
	if the server did not want to respond to request unless they were from		if the server did not want to respond to request unless they were from
	authenticated clients. A server might want to allow unsigned requests		authenticated clients. A server might want to allow unsigned requests
	if the server is authenticating in some other fashion (such as by		if the server is authenticating in some other fashion (such as by
	IP address).		IP address).
	In this specification, the item(s) in the Query item are certificates.		In this specification, the item(s) in the Query item are certificates.
	skipping to change at line 167 ¶		skipping to change at line 176 ¶
	The Version item tells the version of SCVP used in a request or a		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.		response. The value of the Version item for this specification is 1.
	3.4 Query		3.4 Query
	The Query item specifies the object of the request. One type of object		The Query item specifies the object of the request. One type of object
	is defined in this specification: CertsQuery. (Other types of queries		is defined in this specification: CertsQuery. (Other types of queries
	might be specified in the future.) The CertsQuery is a request for		might be specified in the future.) The CertsQuery is a request for
	information on one or more certificates. A CertsQuery contains a list		information on one or more certificates. A CertsQuery contains a list
	of certificates, and can also contain zero or one of each of the		of certificates, and can also optionally contain each of the
	following items: ValidityTime, IntermediateCerts, TrustedCerts,		following items: ValidityTime, IntermediateCerts, TrustedCerts,
	RevocationInfo, PolicyID, ConfigurationIdentifier, and QueryExtensions.		RevocationInfo, PolicyID, ConfigurationIdentifier, and QueryExtensions.
	The list of certificates in the Query item tells the server the		The list of certificates in the Query item tells the server the
	certificate(s) the client wants a reply for. The optional ValidityTime		certificate(s) the client wants a reply for. The optional ValidityTime
	item tells the time at which the client wants to know about. The		item tells the time at which the client wants to know about. The
	optional IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, and		optional IntermediateCerts, TrustedCerts, RevocationInfo, PolicyID, and
	ConfigurationIdentifier items tell the server how to process the		ConfigurationIdentifier items tell the server how to process the
	request.		request.
			[[[Is it valuable to add a URL to a certificate in the query (for
			wireless applications)? If so, how should that be indicated and how
			does it change the fields that should be returned?]]]
	3.5 CertBundle		3.5 CertBundle
	The CertBundle item contains one or more Certs. The order of		The CertBundle item contains one or more Certs. The order of
	the Cert(s) in the bundle is not important.		the Cert(s) in the bundle is not important.
	3.6 Cert		3.6 Cert
	The Cert item contains a complete certificate. The Cert item		The Cert item contains a complete certificate. The Cert item
	contains an identifier for the type of certificate and the octets of		contains an identifier for the type of certificate and the octets of
	the certificate itself. One type of certificate, for PKIX [PKIX], is		the certificate itself. One type of certificate, for PKIX [PKIX], is
	defined, but other types of certificates (such as for OpenPGP		defined, but other types of certificates (such as for OpenPGP
	[OpenPGP]) may be defined in the future.		[OpenPGP]) may be defined in the future.
	3.8 QueryExtensions		3.8 QueryExtensions
	The QueryExtensions item specifies a list of extensions to the SCVP		The QueryExtensions item specifies a list of extensions to the SCVP
	protocol, for example to request additional information about the		protocol. For example to request additional information about the
	certificate(s) in the CertsQuery. The QueryExtensions item contains a		certificate(s) in the CertsQuery. The QueryExtensions item contains a
	sequence of Extension items, each of which contain an ExtnID item,		sequence of Extension items, each of which contain an ExtnID item,
	a Critical item, and an ExtnValue item.		a Critical item, and an ExtnValue item.
	3.9 ExtnID		3.9 ExtnID
	The ExtnID item is an identifier for the extension. It contains		The ExtnID item is an identifier for the extension. It contains
	the OID of the extension.		the OID of the extension.
	3.10 Critical		3.10 Critical
	The Critical item tells whether the extension is critical. The		The Critical item tells whether the extension is critical. The
	values for the item are:		values for the item are:
	False Not critical		False Not critical
	True Critical		True Critical
	In a request, if the Critical item is true, the server MUST		In a request, if the Critical item is true, the server MUST
	NOT process the request unless it understands the extension. In a		NOT process the request unless it understands the extension. In a
	reply, if the Critical item is true, the client MUST NOT		reply, if the Critical item is true, the client MUST NOT
	process the reply unless it understands the extension.		process the response unless it understands the extension.
	3.11 ExtnValue		3.11 ExtnValue
	The ExtnValue item gives the value of an extension. It		The ExtnValue item gives the value of an extension. It
	contains a sequence of octets.		contains a sequence of octets.
	3.12 IntermediateCerts		3.12 IntermediateCerts
	The IntermediateCerts item specifies to the server the intermediate		The IntermediateCerts item specifies to the server the intermediate
	certificates that the server MAY use when forming a certificate chain.		certificates that the server MAY use when forming a certificate chain.
	skipping to change at line 276 ¶		skipping to change at line 289 ¶
	MUST use when forming a certificate chain. The PolicyID item contains		MUST use when forming a certificate chain. The PolicyID item contains
	a URL that, when resolved, defines the policy.		a URL that, when resolved, defines the policy.
	3.16 ConfigurationIdentifier		3.16 ConfigurationIdentifier
	The ConfigurationIdentifier item tells the server the SCVP options that		The ConfigurationIdentifier item tells the server the SCVP options that
	the client wants the server to use. The client can use this option		the client wants the server to use. The client can use this option
	instead of specifying other SCVP configuration such as PolicyID,		instead of specifying other SCVP configuration such as PolicyID,
	TrustedCerts, RevocationInfo, and so on. The value of this item is		TrustedCerts, RevocationInfo, and so on. The value of this item is
	determined by private agreement between the client and the server and		determined by private agreement between the client and the server and
	is not specified in this document. For example, the value might be the		is not specified in this document. The server might want to have
	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		identifiers that indicate that some settings are used in addition to
	others given in the request; in this way, the configuration identifier		others given in the request; in this way, the configuration identifier
	might be a shorthand for some SCVP options.		might be a shorthand for some SCVP options.
	3.17 TypesOfCheck		3.17 TypesOfCheck
	The TypesOfCheck item describes the kind of checking that the client		The TypesOfCheck item describes the kind of checking that the client
	wants the server to do on the certificate(s) in the Query item. If the		wants the server to do on the certificate(s) in the Query item. If the
	TypesOfCheck item is given in a request, it can contain one or more		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		types of checks. For each type of check specified in the request, the
	server MUST perform all the checks requested, or return an error.		server MUST perform all the checks requested, or return an error.
	The types of checks are:		The types of checks are:
	- Path validation to a trusted root		- Build a path to a trusted root
	- Revocation status		- Build a validated path to a trusted root
	Note that revocation status check inherently includes path validation.		- Do revocation status checks on the path
			Note that revocation status check inherently includes path construction.
	3.18 WantBack		3.18 WantBack
	The WantBack item describes the kind of information the client wants		The WantBack item describes the kind of information the client wants
	from the server for the certificate(s) in the Query item. If the		from the server for the certificate(s) in the Query item. If the
	WantBack item is given in a request, it can contain one or more types		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,		of information. For each type of information specified in the request,
	the server MUST return information on what it found during the check.		the server MUST return information on what it found during the check
			(in a successful response).
	The types of information that can be requested are:		The types of information that can be requested are:
	- Certificate chain used to validate the certificate		- Certificate chain built for the certificate
	- Proof of revocation status		- Proof of revocation status
	For example, a request might include a TypesOfCheck item that does not		For example, a request might include a TypesOfCheck item that only specifies
	specify path validation, and include a WantBack item that specifies the		path building, and include a WantBack item that specifies the
	certificate chain used to validate. The response would not include a		certificate chain built. The response would not include a
	status for the validation, but would include a certificate chain that		status for the validation, but would include a certificate chain that
	the server thinks might validate. This set of options might be used by		the server thinks might validate. This set of options might be used by
	a client that wants to do its own path validation.		a client that wants to do its own path validation.
	3.19 ValidityTime		3.19 ValidityTime
	The ValidityTime indicates the time for which the client wants the		The ValidityTime indicates the time for which the client wants the
	information to be relevant. Not specifying a ValidityTime means that		information to be relevant. Not specifying a ValidityTime means that
	the server should use the current time. For example, when asking for		the server should use the current time. For example, when asking for
	validation of a certificate, the client might ask "was this certificate		validation of a certificate, the client might ask "was this certificate
	skipping to change at line 402 ¶		skipping to change at line 415 ¶
	10 Too busy; try again later		10 Too busy; try again later
	20 The structure of the request was wrong		20 The structure of the request was wrong
	21 The version of request is not supported by this server		21 The version of request is not supported by this server
	22 The request included unrecognized items; aborting		22 The request included unrecognized items; aborting
	23 The key given in the RequestSignature is not recognized		23 The key given in the RequestSignature is not recognized
	24 The signature did not match the body of the request		24 The signature did not match the body of the request
	25 The encoding was not understood		25 The encoding was not understood
	26 The request was not authorized		26 The request was not authorized
			27 The request included unsupported items; continuing
			28 The request included unsupported items; aborting
	4.4a RequestHash		4.4a RequestHash
	The RequestHash item is the SHA-1 hash of the PSRequest item. The		The RequestHash item is the SHA-1 hash of the PSRequest item. The
	RequestHash item serves the following purposes:		RequestHash item serves the following purposes:
	- It helps a client know that the request was not maliciously modified		- It helps a client know that the request was not maliciously modified
	when the client gets the response back		when the client gets the response back
	- It allows the client to associate a response with a request when		- It allows the client to associate a response with a request when
	skipping to change at line 425 ¶		skipping to change at line 440 ¶
	client.		client.
	The server MUST return the RequestHash item in the response.		The server MUST return the RequestHash item in the response.
	4.5 ReplyObjects		4.5 ReplyObjects
	The ReplyObjects item returns objects to the client. In this		The ReplyObjects item returns objects to the client. In this
	specification, the ReplyObjects item is always a CertReply, which tells		specification, the ReplyObjects item is always a CertReply, which tells
	the client about a single certificate from the request. The CertReply		the client about a single certificate from the request. The CertReply
	item contains a Cert item identifying the certificate, a		item contains a Cert item identifying the certificate, a
	ReplyStatus item, a ThisUpdate item, and a NextUpdate item. There may		ReplyStatus item, a ThisUpdate item, and an optional NextUpdate item. There
	also be the following optional items: ValidationStatus,		may also be the following optional items: ValidationStatus,
	RevocationStatus, PublicKey, CertSubject, ValidationChain,		RevocationStatus, PublicKey, CertSubject, ValidationChain,
	RevocationProof, and SingleReplyExtensions.		RevocationProof, and SingleReplyExtensions.
	The presence or absence of the ValidationStatus, RevocationStatus,		The presence or absence of the ValidationStatus, RevocationStatus,
	PublicKey, CertSubject, ValidationChain, and RevocationProof items in		PublicKey, CertSubject, ValidationChain, and RevocationProof items in
	the CertReply item is controlled by the TypesOfCheck, and WantBack		the CertReply item is controlled by the TypesOfCheck, and WantBack
	items in the request. A server MUST include one of the above items for		items in the request. A server MUST include one of the above items for
	each related item requested in the TypesOfCheck, and WantBack items.		each related item requested in the TypesOfCheck, and WantBack items.
	4.6 ReplyStatus		4.6 ReplyStatus
	skipping to change at line 478 ¶		skipping to change at line 493 ¶
	information in the CertReply to be valid. The NextUpdate item		information in the CertReply to be valid. The NextUpdate item
	represents the date at UTC. [[[Is there a desire for another item that		represents the date at UTC. [[[Is there a desire for another item that
	says "the server takes liability for this response up to this		says "the server takes liability for this response up to this
	particular time?]]]		particular time?]]]
	4.9 ReplyTypesOfCheck		4.9 ReplyTypesOfCheck
	The ReplyTypesOfCheck contains the responses to the client's		The ReplyTypesOfCheck contains the responses to the client's
	TypesOfCheck item in the request. It has the same form as the		TypesOfCheck item in the request. It has the same form as the
	Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match		Extensions item, and the OIDs in the ReplyTypesOfCheck item MUST match
	the OIDS in the TypesOfCheck item.		the OIDS in the TypesOfCheck item. The criticality bit MUST NOT be set.
	The value for path validation to a trusted root, {type-arc 0}, can be		The value for path building to a trusted root, {type-arc 0}, can be
	one of the following:		one of the following:
	0 Valid		Value Meaning
	1 Not valid		----- -------
	2 Unknown		0 Built a path
			1 Could not build a path
	The value for the revocation status, {type-arc 1}, can be one of the		The value for path validation to a trusted root, {type-arc 1}, can be
			one of the following:
			Value Meaning
			----- -------
			0 Valid
			1 Not valid
			The value for the revocation status, {type-arc 2}, can be one of the
	following:		following:
	0 Good		Value Meaning
	1 Revoked		----- -------
	2 Unknown		0 Good
			1 Revoked
			2 Unknown
	4.10 ReplyWantBack		4.10 ReplyWantBack
	The ReplyWantBack contains the responses to the client's WantBack item		The ReplyWantBack contains the responses to the client's WantBack item
	in the request. It has the same form as the Extensions item, and the		in the request. It has the same form as the Extensions item, and the
	OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack		OIDs in the ReplyWantBack item MUST match the OIDS in the WantBack
	item.		item. The criticality bit MUST NOT be set.
	The value for the certificate chain used to validate the certificate		The value for the certificate chain used to verify the certificate
	in the request, {want-arc 1}, is a CertBundle item.		in the request, {want-arc 0}, is a CertBundle item.
	The value for the proof of revocation status, {want-arc 2}, is a		The value for the proof of revocation status, {want-arc 1}, is a
	RevocationProof item.		RevocationProof item.
	4.11 RevocationProof		4.11 RevocationProof
	The RevocationProof item gives the client the proof that the server		The RevocationProof item gives the client the proof that the server
	used to check revocation. The structure of the RevocationProof item is		used to check revocation. The structure of the RevocationProof item is
	the same as an Extensions item. The OIDs in the RevocationProof item		the same as an Extensions item. The OIDs in the RevocationProof item
	are the same as those in the RevocationInfo item.		are the same as those in the RevocationInfo item.
	4.12 ResponseSignature		4.12 ResponseSignature
	skipping to change at line 628 ¶		skipping to change at line 654 ¶
	psResponse PSResponse,		psResponse PSResponse,
	responseSignature [0] Signature OPTIONAL		responseSignature [0] Signature OPTIONAL
	}		}
	PSResponse ::= SEQUENCE {		PSResponse ::= SEQUENCE {
	version INTEGER,		version INTEGER,
	producedAt GeneralizedTime,		producedAt GeneralizedTime,
	responseStatus ResponseStatus,		responseStatus ResponseStatus,
	requestHash OCTET STRING,		requestHash OCTET STRING,
	replyObjects [0] ReplyObjects OPTIONAL,		replyObjects [0] ReplyObjects OPTIONAL,
	requestNonce [2] OCTET STRING OPTIONAL,		requestNonce [1] OCTET STRING OPTIONAL,
	respExtensions [3] Extensions OPTIONAL		respExtensions [2] Extensions OPTIONAL
	}		}
	ResponseStatus ::= SEQUENCE {		ResponseStatus ::= SEQUENCE {
	statusCode INTEGER,		statusCode INTEGER,
	errorMessage [0] UTF8String OPTIONAL		errorMessage [0] UTF8String OPTIONAL
	}		}
	ReplyObjects ::= CHOICE {		ReplyObjects ::= CHOICE {
	certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply		certReplies [0] SEQUENCE SIZE (1..MAX) OF CertReply
	}		}
	CertReply ::= SEQUENCE {		CertReply ::= SEQUENCE {
	cert Cert,		cert Cert,
	replyStatus ReplyStatus,		replyStatus ReplyStatus,
	thisUpdate GeneralizedTime,		thisUpdate GeneralizedTime,
	nextUpdate GeneralizedTime,		nextUpdate [0] GeneralizedTime OPTIONAL,
	replyTypesOfCheck [0] Extensions OPTIONAL,		replyTypesOfCheck [1] Extensions OPTIONAL,
	replyWantBack [1] Extensions OPTIONAL,		replyWantBack [2] Extensions OPTIONAL,
	singleReplyExtensions [2] Extensions OPTIONAL		singleReplyExtensions [3] Extensions OPTIONAL
	}		}
			-- The encoding of the value for path validation and revocation status
			-- will be as an INTEGER
	ReplyStatus ::= ENUMERATED {		ReplyStatus ::= ENUMERATED {
	success (0),		success (0),
	certTypeUnrecognized (1),		certTypeUnrecognized (1),
	typeOfCheckUnrecognized (2),		typeOfCheckUnrecognized (2),
	wantBackUnrecognized (3),		wantBackUnrecognized (3),
	certMalformed (4),		certMalformed (4),
	policyIDUnrecognized (5),		policyIDUnrecognized (5),
	configInfoUnrecognized (6),		configInfoUnrecognized (6),
	unauthorizedRequest (7)		unauthorizedRequest (7)
	}		}
	skipping to change at line 800 ¶		skipping to change at line 829 ¶
	<!ELEMENT ReplyObjects ( CertReplies )>		<!ELEMENT ReplyObjects ( CertReplies )>
	<!ELEMENT RespExtensions (Extension+)>		<!ELEMENT RespExtensions (Extension+)>
	<!ELEMENT CertReplies ( CertReply+ )>		<!ELEMENT CertReplies ( CertReply+ )>
	<!ELEMENT CertReply ( Cert,		<!ELEMENT CertReply ( Cert,
	ReplyStatus,		ReplyStatus,
	ThisUpdate,		ThisUpdate,
	NextUpdate,		NextUpdate?,
	ReplyTypesOfCheck?,		ReplyTypesOfCheck?,
	ReplyWantBack?,		ReplyWantBack?,
	SingleReplyExtensions? )>		SingleReplyExtensions? )>
	<!ELEMENT ThisUpdate ( GeneralizedTime )>		<!ELEMENT ThisUpdate ( GeneralizedTime )>
	<!ELEMENT NextUpdate ( GeneralizedTime )>		<!ELEMENT NextUpdate ( GeneralizedTime )>
	<!ELEMENT ReplyTypesOfCheck ( Extensions )>		<!ELEMENT ReplyTypesOfCheck ( Extensions )>
	skipping to change at line 947 ¶		skipping to change at line 976 ¶
	If the client does not check the signature on the response, a		If the client does not check the signature on the response, a
	man-in-the-middle attack could fool the client into believing modified		man-in-the-middle attack could fool the client into believing modified
	responses from the server, or responses to questions the client did not		responses from the server, or responses to questions the client did not
	ask. This attack does not affect the usefulness of some responses (such		ask. This attack does not affect the usefulness of some responses (such
	as a response that returns a certificate path that the client will		as a response that returns a certificate path that the client will
	validate itself) but does affect things such as a validation response.		validate itself) but does affect things such as a validation response.
	If the client does not include a RequestNonce item, or if the client		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		does not check that the RequestNonce in the reply matches that in the
	request, an attacker can replay previous responses from the server.		request, an attacker can replay previous responses from the server.
	This attack can also be mounted, even with signed requests, if the
	server does not keep track of previous RequestNonce items.
	If the server does not require some sort of authorization (such as		If the server does not require some sort of authorization (such as
	signed requests), an attacker can get the server to reply to arbitrary		signed requests), an attacker can get the server to reply to arbitrary
	requests. Such responses may give the attacker information about		requests. Such responses may give the attacker information about
	weaknesses in the server or about the timeliness of the server's		weaknesses in the server or about the timeliness of the server's
	checking. This information may be valuable for a future attack.		checking. This information may be valuable for a future attack.
	A. References		A. References
	[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement		[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
	skipping to change at line 979 ¶		skipping to change at line 1006 ¶
	[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.		[UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279.
	[XMLDSIG] NEED THE REFERENCE		[XMLDSIG] NEED THE REFERENCE
	B. Acknowledgments		B. Acknowledgments
	The lively debate in the PKIX Working Group also had a significant		The lively debate in the PKIX Working Group also had a significant
	impact on the types of items described in this protocol. Denis Pinkas		impact on the types of items described in this protocol. Denis Pinkas
	suggested some additional requirements for the protocol, and Mike Myers		suggested some additional requirements for the protocol, and Mike Myers
	helped point out sections that needed clarification.		helped point out sections that needed clarification. Frank
			Balluffi and Ameya Talwalkar were responsible for the first
			implementation and suggestions on a few deficiencies in the document.
	C. Changes Between Versions of This Document		C. Changes Between Versions of This Document
	C.1 Differences between -00 and -01		C.1 Differences between -00 and -01
	1: Rewrote to both narrow focus and to explain the goals more fully.		1: Rewrote to both narrow focus and to explain the goals more fully.
	1.1: Removed second paragraph.		1.1: Removed second paragraph.
	2: Removed the discussion of the two syntaxes.		2: Removed the discussion of the two syntaxes.
	skipping to change at line 1229 ¶		skipping to change at line 1258 ¶
	25. Changed a line in section 3.14, first para (about where a client		25. Changed a line in section 3.14, first para (about where a client
	may have obtained an OCSP response to send to the SCVP server).		may have obtained an OCSP response to send to the SCVP server).
	26. Got rid of the multiple places where we say what is signed by the		26. Got rid of the multiple places where we say what is signed by the
	RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also		RequestSignature or ResponseSignature (e.g. section 3.1 and 3.2). Also
	simplified the definition of the RequestSignature and		simplified the definition of the RequestSignature and
	ResponseSignature in sections 3 and 4. The should be defined in detail		ResponseSignature in sections 3 and 4. The should be defined in detail
	in the encoding sections.		in the encoding sections.
			C.4 Difference between -03 and -04
			1. Added format information in the http header in Appendix E.1.1
			2. Changed the numbers in the want-arc to start with 0 in section 4.10
			3. Added error states to indicate that the request contained
			unsupported items in section 4.4.
			4. Added acknowledgement to Frank Balluffi and Ameya Talwalkar in
			Appendix B.
			5. Made nextUpdate optional (renumbered tags in CertReply).
			6. Specified the criticality bit in ReplyTypesOfCheck and ReplyWantBack
			(sections 4.9 and 4.10)
			7. Specified the encoding for the replyTypesOfCheck field
			8. Renumbered tag fields for PSResponse.
			9. Added a TODO to section 3.4 about Cert URLs.
			10. Corrected the section on the ConfigurationIdentifier.
			11. Modified TypesOfCheck to allow client to request a non-validated
			path.
			12. Removed an old (unneeded) line in the security section.
	D. MIME Registrations		D. MIME Registrations
	D.1 application/scvp-request		D.1 application/scvp-request
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type application/scvp-request		Subject: Registration of MIME media type application/scvp-request
	MIME media type name: application		MIME media type name: application
	MIME subtype name: scvp-request		MIME subtype name: scvp-request
	Required parameters: None		Required parameters: format
	Optional parameters: None		Optional parameters: None
	Encoding considerations: binary or XML		Encoding considerations: binary or XML
	Security considerations: Carries a request for information. This		Security considerations: Carries a request for information. This
	request may optionally be cryptographically signed.		request may optionally be cryptographically signed.
	Interoperability considerations: None		Interoperability considerations: None
	skipping to change at line 1279 ¶		skipping to change at line 1338 ¶
	D.2 application/scvp-response		D.2 application/scvp-response
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type application/scvp-response		Subject: Registration of MIME media type application/scvp-response
	MIME media type name: application		MIME media type name: application
	MIME subtype name: scvp-response		MIME subtype name: scvp-response
	Required parameters: None		Required parameters: format
	Optional parameters: None		Optional parameters: None
	Encoding considerations: binary or XML		Encoding considerations: binary or XML
	Security considerations: Carries a cryptographically signed response		Security considerations: Carries a cryptographically signed response
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: IETF PKIX Working Group Draft on Simple		Published specification: IETF PKIX Working Group Draft on Simple
	Certificate Validation Protocol - SCVP		Certificate Validation Protocol - SCVP
	Applications which use this media type: SCVP servers		Applications which use this media type: SCVP servers
	skipping to change at line 1316 ¶		skipping to change at line 1376 ¶
	E. SCVP data format		E. SCVP data format
	E.1 SCVP over HTTP		E.1 SCVP over HTTP
	This section describes the formatting that will be done to the		This section describes the formatting that will be done to the
	request and response to support HTTP.		request and response to support HTTP.
	E.1.1 Request		E.1.1 Request
	HTTP based SCVP requests can the POST method to		HTTP based SCVP requests can use the POST method to
	submit their requests. Where privacy is		submit their requests. Where privacy is
	a requirement, SCVP transactions exchanged using HTTP MAY be		a requirement, SCVP transactions exchanged using HTTP MAY be
	protected using either TLS/SSL or some other lower layer protocol.		protected using either TLS/SSL or some other lower layer protocol.
	An SCVP request using the POST method is constructed as follows: The		An SCVP request using the POST method is constructed as follows: The
	Content-Type header MUST have the value "application/scvp-request"		Content-Type header MUST have the value "application/scvp-request".
	while the Content-Length header MUST be present and have the exact		In addition, the format of the message must be specified as either
	length of the request. The body of the message is the binary value		"format=xml" or "format=asn1". The Content-Length header MUST be present
	of the DER encoding of the FullRequest, or XML encoding of		and have the exact length of the request. The body of the message is the
	FullRequest. Other HTTP headers MAY be present and MAY		binary value of the DER encoding of the FullRequest, or XML
			encoding of FullRequest. Other HTTP headers MAY be present and MAY
	be ignored if not understood by the requestor.		be ignored if not understood by the requestor.
			Sample Content-Type headers are:
			Content-Type: application/scvp-request;format=xml
			Content-Type: application/scvp-request;format=asn1
	E.1.2 Response		E.1.2 Response
	An HTTP-based SCVP response is composed of the appropriate HTTP		An HTTP-based SCVP response is composed of the appropriate HTTP
	headers, followed by the binary value of the DER encoding of the		headers, followed by the binary value of the DER encoding of the
	FullResponse or XML encoding of FullResponse. The Content-Type		FullResponse or XML encoding of FullResponse. The Content-Type
	header MUST have the value "application/scvp-response". The		header MUST have the value "application/scvp-response".
			In addition, the format of the message must be specified as either
			"format=xml" or "format=asn1". The
	Content-Length header MUST be present and specify		Content-Length header MUST be present and specify
	the length of the response. Other HTTP headers MAY be present and MAY		the length of the response. Other HTTP headers MAY be present and MAY
	be ignored if not understood by the requestor.		be ignored if not understood by the requestor.
	F. Author Contact Information		F. Author Contact Information
	Ambarish Malpani		Ambarish Malpani
	ValiCert, Inc.		ValiCert, Inc.
	339 N. Bernardo Ave.		339 N. Bernardo Ave.
	Mountain View, CA 94043		Mountain View, CA 94043
	ambarish@valicert.com		ambarish@valicert.com
	Paul Hoffman		Paul Hoffman
	VPN Consortium		VPN Consortium
	127 Segre Place		127 Segre Place
	Santa Cruz, CA 95060 USA		Santa Cruz, CA 95060 USA
	paul.hoffman@vpnc.org		paul.hoffman@vpnc.org
			Russell Housley
			SPYRUS
			381 Elden Street
			Suite 1120
			Herndon, VA 20170 USA
			housley@spyrus.com
End of changes. 40 change blocks.
	62 lines changed or deleted		129 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/