draft-ietf-pkix-cvp-01.txt

PKIX的RFC英文文档

   cvpMsg         '00'H    DER-encoded CVP message
     -- CVP message
   pollRep        '01'H    polling reference (32 bits),
                           time-to-check-back (32 bits)
     -- poll response where no CVP message response ready; use polling
     -- reference value (and estimated time value) for later polling
   pollReq        '02'H    polling reference (32 bits)
     -- request for a CVP message response to initial message
   negPollRep     '03'H    '00'H
     -- no further polling responses (i.e., transaction complete)
   partialMsgRep  '04'H    next polling reference (32 bits),
                           time-to-check-back (32 bits),
                           DER-encoded CVP message
     -- partial response (receipt) to initial message plus new polling
     -- reference (and estimated time value) to use to get next part of
     -- response
   finalMsgRep    '05'H    DER-encoded CVP message
     -- final (and possibly sole) response to initial message
   errorMsgRep    '06'H    human readable error message
     -- produced when an error is detected (e.g., a polling reference
     -- is received which doesn't exist or is finished with)

The sequence of messages that can occur is:

   a) entity sends cvpMsg and receives one of pollRep, negPollRep,
      partialMsgRep, or finalMsgRep in response.

   b) end entity sends pollReq message and receives one of
      negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in
      response.

The "time-to-check-back" parameter is an unsigned 32-bit integer. It is 
the time in seconds indicating the minimum interval after which the 
client SHOULD check the status again.

It provides an estimate of the time that the end entity should send its 
next pollReq.





Pinkas                                                        [Page 24]

Internet Draft                   CVP                       October 2002


8.2. CVP via HTTP

ASN.1-encoded messages are wrapped with by MIME objects.

   Two MIME objects are specified as follows.

   Content-Type: application/pkcval-query
      <<the ASN.1 DER-encoded CVPRequest message>>

   Content-Type: application/pkcval-reply
      <<the ASN.1 DER-encoded CVPResponse message>>

   These MIME objects can be sent and received using common HTTP
   processing engines over WWW links and provides a simple browser-
   server transport for CVP messages.

   Upon receiving a valid request, the server MUST respond with either 
   a valid response with content type application/pkcval-response or
   with an HTTP error.

8.3 CVP using Email

The DER encoded CVPRequest and CVPResponses are encapsulated using 
MIME objects.

   Two MIME objects are specified as follows:

   Content-Type: application/pkcval-query
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded CVPRequest message, base64-encoded>>

   Content-Type: application/pkcval-reply
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded CVPRequest message, base64-encoded>>

These MIME objects can be respectively sent and received using common
MIME processing engines and provides a simple Internet mail transport
for public key certificate validation messages.

For the application/pkcval-query and application/pkcval-reply MIME 
types, implementations SHOULD include the optional "name" and 
"filename" parameters. Including a file name helps preserve type 
information when certificate validation queries and replies are saved 
as files. 

When these parameters are included, a file name with the appropriate 
extension SHOULD be selected:

           MIME Type                     File Extension
      application/pkcval-query            .CVQ
      application/pkcval-reply            .CVR



Pinkas                                                        [Page 25]

Internet Draft                   CVP                       October 2002


In addition, the file name SHOULD be limited to eight characters 
followed by a three letter extension. The eight character filename base 
can be any distinct name.

9. Security considerations

A CVP client must trust a CVP server to provide the correct answer. 
However, this does not mean that all CVP clients will trust the same 
CVP servers. While a positive answer might be sufficient for one CVP 
client, that same positive answer will not necessarily convince 
another CVP client.

Other clients may trust their own CVP servers, or they might perform 
certification path validation themselves. CVP clients operating under 
an organizational validation policy must ensure that each of the CVP 
servers they trust is operating under that organizational validation 
policy.

When no policy reference is present in the CVP request, the CVP client 
ought to verify that the policy selected by the CVP server is 
appropriate.

The revocation status information is obtained for the validation time. 

In case of the verification of a certificate used to verify a digital 
signature, the validation time is not necessarily identical to the time 
when the corresponding private key was used. 

The validation time ought to be adjusted by the CVP client to 
compensate for:

   1) time for the end-entity to realize that its private key has 
      been or could possibly be compromised, and/or

   2) time for the end-entity to report the key compromise, and/or

   3) time for the revocation authority to process the revocation 
      request from the end-entity, and/or

   4) time for the revocation authority to update and distribute the 
      revocation status information.

10. Acknowledgments

   To be provided.









Pinkas                                                        [Page 26]

Internet Draft                   CVP                       October 2002


11. Normative references

   [RFC2119]

     Key words for use in RFCs to Indicate Requirement Levels.
     S.Bradner. March 1997

   [RFC3280]

      Internet X.509 Public Key Infrastructure.
      Certificate and CRL Profile. RFC 3280
      R. Housley, W. Ford, W. Polk, D. Solo.
      April 2002.

   [RFC3379] 

      Delegated Path Validation and Delegated Path Discovery
      Protocol Requirements. RFC 3379. R. Housley, D.Pinkas. 
      September 2002

   [OCSP] 

      X.509 Internet Public Key Infrastructure. 
      Online Certificate Status Protocol - OCSP. RFC 2560
      M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.

   [TSP]

      Internet X.509 Public Key Infrastructure
      Time-Stamp Protocol (TSP). RFC 3161
      C. Adams, P. Cain, D. Pinkas, R. Zuccherato.

   [RFC3126]

      Electronic Signature Formats for long term electronic signatures
      D. Pinkas, J. Ross, N. Pope. RFC 3126.

   [RFC2634] 

      Enhanced Security Services for S/MIME. P. Hoffman. RFC 2634. 
      June 1999.


12. Authors' addresses

   Denis Pinkas
   Bull
   Rue Jean Jaures
   78340 LES Clayes-sous-Bois
   FRANCE
   e-mail: [e-mail]



Pinkas                                                        [Page 27]

Internet Draft                   CVP                       October 2002


13. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



























Pinkas                                                        [Page 28]

Internet Draft                   CVP                       October 2002




Annex A (normative): ASN.1 Definitions

To be provided.

















































Pinkas                                                        [Page 29]