Subject: I-D ACTION:draft-ietf-pkix-scvp-22.txt

From: [email-masked]
Date: Mon, 23 Jan 2006 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Standard Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-22.txt
	Pages		: 82
	Date		: 2006-1-23
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-22.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-22.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-22.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Peter Rybar <[email-masked]>
Date: Tue, 24 Jan 2006 09:03:31 +0100

Hello,

I am very pleased to see your document which supersedes obsolete RFC 3280.

I compared the draft with the old RFC 3280 and I identified there 
several useful requirements that are similar to requirements published 
in documents on our web:
http://www.nbusr.sk/NBU_SEP/en_9.php
http://www.nbusr.sk/NBU_SEP/en_10.php
http://www.nbusr.sk/NBU_SEP/en_11.php
http://www.nbusr.sk/NBU_SEP/11_2.php  - finalCertCrl.zip

Our intend was to prepare easy readable documents containing simply 
understandable description of some standards and the best practices.
The documents can be helpful for SW developer, auditors or users to get 
a better view in a short time of the usage X.509 certificates in 
qualified electronic signatures.

Let me present some additional ideas which I considered to be useful in 
your draft.

Under the mandatory requirements:

If CRL1 (OCSP1) is issued then it is not possible to issue such CRL2 
(OCSP2) which would revoke a certificate before issuing time of CRL1 
(OCSP1) in which certificate has not been revoked yet.

It is useful in the verification process, because verification algorithm 
need found only one CRL (OCSP) issued after required time and it does 
not need to wait the whole caution (grace) period.

Under the optional requirements:

I recommend that certificate in the CRL (OCSP) can not be found in 
revocation reason certificateHold or removeFromCRL, thus its validity 
can not be stopped for certain period.
It eases verifying algorithms and enables to employ only final complete 
CRL and avoid SW application to collect all issued CRL to check if some 
certificate maybe has been in status certificateHold and removeFromCRL.

These CA practices are currently common in some countries as it was 
discussed with some participant at ETSI meeting in Sophia Antipolis in 
January and are useful in long term validation.

Best regards

Peter Rybar
National Security Authority of the Slovak Republic

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 26 Jan 2006 18:18:57 -0500

>http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-22.txt
I have posted a "diff" file on the NIST Web site showing the differences 
between drafts 21 and 22 of SCVP.  It is available at:

http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-21_to_22.html

Draft 22 includes changes that were made to address the requirement for 
algorithm agility, but does not include changes to address any other issues.

As was agreed during the November IETF meeting, ESSCertID has been 
replaced with a data structure that allows the use of any hash algorithm 
rather than being limited to SHA-1.  The hash algorithm used to compute 
the hash of the certificate is specified as part of the data structure.  
The default value for the hash algorithm is SHA-1, so that the DER 
encoding of the data structure is the same as the DER encoding of 
ESSCertID when SHA-1 is used.

Since ESSCertID was the only data structure that hard coded the use of a 
particular cryptographic algorithm, no other data structures needed to 
be changed to allow for algorithm agility.  However, changes needed to 
be made to the protocol in order to allow the client and server to 
signal their capabilities to each other.

In draft 22, the SCVP server signals its capabilities to the client in 
its validation policy response message.  When the client is using 
cryptography in creating its request message, it should choose 
cryptographic algorithms based on the server's indicated capabilities.  
When the server will need to use cryptography in creating the response, 
the client should indicate which algorithm(s) the server should use by 
selecting from the set of algorithms that the server indicates in its 
validation policy response message that it can support.

There are four places that cryptography is used: when the client sends 
an authenticated request to the server; when the server sends an 
authenticated response to the client; when a certificate is specified by 
reference; and when the response includes a hash of the request.

Authenticated request messages may be either digitally signed or MACed.  
For digitally signed request messages, the server indicates the set of 
digital signature algorithms that it is capable of validating 
(signatureVerification).  When key agreement is used, the 
serverPublicKeys item in the validation policy response message 
indicates the set of key agreement keys that the server holds along with 
the key derivation function (KDF) and MAC algorithm that should be used 
with each key.  When pre-shared secret keys are used, it is expected 
that the client will know what MAC algorithm to use through out-of-band 
means.

It is expected that the server's response will be protected with a MAC 
only if the client's request was similarly protected or if there is a 
pre-shared secret key between the client and server.  If the client's 
request was protected with a MAC, the server will use the same 
algorithm(s) to protect the response.  In the case of pre-shared secret 
keys, it is expected that the algorithm to use will be determined 
through out-of-band means.

For digitally signed response messages (CVResponse messages), the server 
indicates in its validation policy response message the set of 
algorithms with with it can sign (signatureGeneration).  That is, it 
lists the algorithms for which its cryptographic module is capable of 
generating the signature and for which it has a certified public key.  
The first algorithm in the signatureGeneration sequence is designated as 
the server's default signature algorithm.  Clients requesting a 
digitally signed CVResponse message may either accept the server's 
default signature algorithm or may specify that the response is to be 
signed using one of the other algorithms listed in the 
signatureGeneration item from the server's validation policy response 
message.

The server's validation policy response message also indicates the set 
of hash algorithms that the server supports (hashAlgorithms), with the 
algorithm in the sequence being the server's default hash algorithm.  If 
the client includes a certificate by reference in its request (either in 
the queriedCerts or trustAnchors item, then the client must use one of 
these algorithms to compute the certHash.  If the client wishes the 
server's response message to include a hash of the request 
(requestHash), the client may either accept the server's default hash 
algorithm or may specify which of the hash algorithms from the 
hashAlgorithms item in the server's validation policy response message 
the server is to use to compute requestHash.

Dave