Internet DRAFT - draft-adams-dcs

draft-adams-dcs



                                          C. Adams(Entrust Technologies)
Internet Draft                       R. Zuccherato(Entrust Technologies)
expires in six months                                       June 4, 1998


                  Data Certification Server Protocols 

                       <draft-adams-dcs-00.txt>


Status of this Memo

This document is an Internet-Draft.  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."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

Abstract

This document describes a general data certification service and the 
protocols to be used when communicating with it.  The Data Certification 
Server  is a Trusted Third Party (TTP) that can be used as one component 
in building reliable non-repudiation services (see [ISONR]).  Useful 
Data Certification Server responsibilities in a PKI are to validate 
signatures and to provide up-to-date information regarding the status of 
public key certificates.  We give examples of how to use the Data 
Certification Server to extend the lifetime of a signature beyond key 
expiry or revocation and to query the Data Certification Server 
regarding the status of a public key certificate.

      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',  'MAY', and
      'OPTIONAL' in this document are to be interpreted as described in
      RFC 2119 [RFC2119].

1. Introduction

A Data Certification Server (DCS) is a Trusted Third Party that verifies 
the correctness of specific data submitted to it.  The Data 
Certification Server provides the data certification service in order 
that non-repudiation evidence may be constructed relating to the 
validity and correctness of an entity's claim to possess data, the 
validity and revocation status of an entity's public key certificate 
and/or the validity and correctness of another entity's signature.  When 
certifying possession of data or another entity's signature, the DCS 

Document Expiration:  December 4, 1998                            Page 1

verifies the mathematical correctness of the actual signature value 
contained in the request and also checks the full certification path 
from the signing entity to a trusted point (e.g., the DCS's CA, or the 
root CA in a hierarchy).  The DCS MAY be able to rely on all relevant 
CRLs and ARLs, or the DCS MAY need to supplement this with access to 
more current status information from the CA.  It then includes a trusted 
time and creates a data certification token.  (See Appendix B.)

When certifying a public key certificate, the DCS verifies that the 
certificate included in the request is a valid certificate and 
determines its revocation status at a specified time.  Again, it checks 
the full certification path from the certificate signing entity to a 
trusted point.  The DCS MAY be able to rely on all relevant CRLs and 
ARLs, or the DCS MAY need to supplement this with access to more current 
status information from the CA.  It includes this information, along 
with a trusted time, to create a Data Certification Token.  (See 
Appendix C.)

The presence of a data certification token supports non-repudiation in 
two ways.  It provides evidence that a signature or public key 
certificate was valid at thetime indicated in the token.  The token can 
be used even after the corresponding public key certificate expires and 
its revocation information is no longer available on CRLs (for example).  
The production of a data certification token in response to a signed 
request for certification of another signature or public key certificate 
also provides evidence that due diligence was performed by the requester 
in validating the signature or public key certificate.

It is not recommended that the DCS be used as a substitute for normal 
public keycertificate revocation checking (e.g. CRLs, OCSP) in large 
environments, due to concerns about the scalability of this protocol.  
It should only be used to support non-repudiation or to supplement more 
traditional revocation services when more timely information is 
required.

In all cases, the trust that PKI entities have in the Data Certification 
Server is transferred to the contents of the data certification token 
(just as trust in a CA is transferred to the public key certificates 
that it issues).  As a particular example, a data certification token 
pertaining to a signature may be useful for extending the life of that 
signature beyond the expiry or subsequent revocation of its 
corresponding verification certificate.

2. Requirements of the Data Certification Server 

The Data Certification Server  is REQUIRED to:

     1. verify the correctness of the enclosed digital signature using 
        all appropriate status information and public key certificates 
        and produce a signed data certification token attesting to the 
        validity of the signature, if asked by the requester.
     2. verify the validity (according to [CCP]) of the enclosed public 
        key certificate and its revocation status at the specified time
        using all appropriate status information and public key 
        certificates and produce a signed data certification token 
        attesting to the validity and revocation status of the public 

Document Expiration:  December 4, 1998                            Page 2

        key certificate, if asked by the requester.
     3. include a monotonically incrementing value of the time of day 
        or a time stamp token into its data certification token.
     4. include within each signed data certification token an 
        identifier to uniquely determine the trust and validation policy 
        used for this signature.
     5. sign each data certification token using a key generated 
        exclusively for this purpose and have this property of the key 
        indicated on the corresponding public key certificate.
     6. indicate in the token whether or not the signature or public key
        certificate verified, and if not, the reason the verification 
        failed.
     7. provide a signed receipt (i.e., in the form of an appropriately
        defined data certification token) to the requester, where 
        appropriate, as defined by policy.

3. Data Certification Server Transactions

As the first transaction of this mechanism, the requesting entity 
requests a certification by sending a request (which is or includes a 
data certification request, as defined below), including the data for 
which validity and/or possession is to be certified, to the Data 
Certification Server.  Upon receiving the request, the Data 
Certification Server reviews and checks the validity of the request.  A 
valid request is of the form described in Section 5 of this document, 
can be properly decoded, and is from a supported Data Certification 
Server subscriber.  If the request is valid, the Data Certification 
Server  performs the certification and sends a response (which is or 
includes a data certification token, as defined below) to the requesting 
entity.  Otherwise, the Data Certification Server returns an error 
message (i.e., in the form of an appropriately defined data 
certification token).

Upon receiving the token, the requesting entity verifies its validity.
The requester SHOULD verify that it contains the correct time, the 
correct name for the DCS, the correct data imprint, a valid signature, 
and satisfactory status, service and policy fields.  Since the DCS's 
certificate may have been revoked, the appropriate status information
SHOULD be checked to verify that the certificate is still valid.  The 
token can now be used to authenticate the correctness or possession of 
the corresponding data.

4. Identification of the DCS

The DCS MUST sign all data certification messages with a key reserved 
specifically for that purpose.  The corresponding certificate MUST 
contain the extended key usage field extension as defined in [CCP] 
Section 4.2.1.14 with KeyPurposeID having value id-kp-dcs.  This 
extension MUST be critical.

id-kp-dcs    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Certifying the validity of certain information.  Key usage bits 
  -- that may be consistent:  digitalSignature, nonRepudiation




Document Expiration:  December 4, 1998                            Page 3

5. Request and Token Formats

The ServiceType type indicates which type of Data Certification Server 
Service is required.

ServiceType ::= INTEGER  { cpd(1), cs(2), cpkc(3) }

The value cpd (Certify Possession of Data) is used when only the 
signature on the data certification request (i.e., possession of the 
data in the request) is to be verified.  In this case the Data 
Certification Server  would be merely providing evidence that the 
requester possessed the data in the request and a valid signature key at 
the time indicated.  This is really an extension of the Time Stamp 
Authority [TSA] in that we are given the additional assurance about the 
validity of the signature, as well as the time before which it was 
applied.  The value cs (Certify Signature) is used when another entity's 
signature is to be validated.  The resulting token can then be used to 
support non-repudiation services or to allow use of the signature beyond 
public key certificate revocation or expiry.

The value cpkc (Certify Public Key Certificate) is used when the 
validity and revocation status of the public key certificates included 
in the request are to be verified.  This service can be used to 
supplement the use of CRLs when timely information regarding a 
certificate's revocation state is required (e.g. high value funds 
transfer or the compromise of a highly sensitive key) or when evidence 
supporting non-repudiation is required.  A given DCS MAY support any 
subset of the above services. 

Upon receiving a signed request for either service cs or cpkc the DCS 
MUSTalso verify the signature on the request as is done for the cpd 
service.  Note however, that signed requests for the cs or cpkc service 
are not required.

A data certification request is as follows.  It is encapsulated as a 
SignedData construct [CMS].  The content is of type DCSReqData, which is 
indicated by the OID:

DCSReqData OBJECT IDENTIFIER  ::= { ??????  }

The data certification request MUST either be unsigned or contain only 
the signature of the requester.

The data and information that will be certified are contained in the 
content field of the SignedData content type.

DCSReqData ::= SEQUENCE  {
     dcsReqInfo                DCSReqInfo,
     data                         Data
       --the data to be certified
       --this field MUST be of type Message if the service type is cs 
       --and of type SEQUENCE OF Certificate if the service type is cpkc
}

The dcsReqInfo field contains information pertaining to the data 
certification request.

Document Expiration:  December 4, 1998                            Page 4

DCSReqInfo ::= SEQUENCE  {
     version                      Integer { v1(0) },
     service                      ServiceType,
     requester                    GeneralName OPTIONAL,
      --MUST be present if the service field is cpd
      --MUST match the identity (subjectName or subjectAltName 
      --extension) for the corresponding signing certificate
     reqPolicy                    PolicyInformation OPTIONAL,
     dcs                       GeneralName OPTIONAL,
     nonce                        Integer,
     reqTime                      ReqTime OPTIONAL,
     extensions                   Extensions OPTIONAL   }

ReqTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

In situations where the Data Certification Server  will verify the 
identity of the requester (i.e., when the service field is cpd), the 
data certification request MUST be signed by the requester using the 
signerInfos field.

Similarly, in situations where the Data Certification Server  will 
certify the time included in the request (i.e., when stipulated by the 
policy of the Data Certification Server ), the data certification 
request MUST include the reqTime field in DCSReqInfo. Thus, when 
verifying a public key certificate, the presence of this field indicates 
the time for which the validity and revocation status of the certificate 
SHOULD be reported.  If this field is not present, the current time is 
assumed. TimeStampToken is defined in Sect 2.4 of [TSA].

PolicyInformation is defined in Section 4.2.1.5 of [CCP].  The 
reqPolicy field SHOULD indicate the policy under which the certification 
is requested.  This field MUST be checked by the DCS to verify agreement 
with its own policy.  The absence of this field indicates that any 
policy is acceptable.

The Data type is defined to be either the message itself, a hash of 
the message (this allows a signature indicating possession of private 
data to be certified) or the certificate to be verified.  

Data ::= CHOICE  {
     message                [0]  Message,
     messageimprint         [1]  MessageImprint,
     certs                  [2]  SEQUENCE SIZE (1..MAX) OF 
                                           TargetandChain   }

In order to specify the format (i.e. the type) of the message so that
it may be parsed and understood by the DCS or any verifying entity, we 
define the Message data type.

Message ::= SEQUENCE  {
     format                       MESSAGECLASS.&id,   --objid
     rawdata                      MESSAGECLASS.&Type  --open type  
}


Document Expiration:  December 4, 1998                            Page 5

MESSAGECLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

Possible message types include id-data and id-signedData [CMS].

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

In particular, if the message type is id-signedData (or any other 
message type that allows more than one signature) and more than one
SignerInfo (or signature) is present under service type cs, the DCS 
MUST verify all signatures present.  In this case the failure of any 
one signature to verify will result in the failure of the entire 
certification.

If the requester prefers to send a hash of the message instead, the
MessageImprint data type SHOULD be used.

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field SHOULD be a 
"strong" hash algorithm (that is, it SHOULD be one-way and collision 
resistant).  It is up to the Data Certification Server to decide whether 
or not the given hash algorithm is sufficiently "strong" (based on the 
current state of knowledge in cryptanalysis and the current state of the 
art in computational resources, for example).

The hashedMessage field SHOULD contain the hash of the DER encoding of
the message expressed as a Message data type.  The hash is represented 
as an OCTET STRING.

TargetandChain ::= SEQUENCE {
     target                       Certificate,
     chain                        SEQUENCE SIZE (1..MAX) OF Certificate 
                                        OPTIONAL,
     pathProcInput                PathProcInput OPTIONAL  }

PathProcInput ::= SEQUENCE {
     acceptablePolicySet          CertPolicySet,
     inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
     explicitPolicyReqd           BOOLEAN DEFAULT FALSE }

The certs field SHOULD contain the certificate to be certified.  Each 
certificate SHALL be included in a separate instance of TargetandChain.  
The target field SHALL contain the cert to be verified and the chain 
field, if present, MUST indicate the chain of trust to be used when 
certifying the certificate.  The pathProcInput field, if present, SHOULD 
indicate the acceptable policy set and initial settings for 
explicit-policy-indicator and inhibit-policy-mapping indicators to be 

Document Expiration:  December 4, 1998                            Page 6

used in X.509 public key certificate path validation (see [CCP]).

Extensions are described in Section 4.2 of [CCP].  The criticality of 
the extensions MUST be honoured by conformant DCSs and clients (e.g. 
requests and responses containing critical extensions which are not 
understood MUST be rejected).

A data certification token is as follows.  It is encapsulated as a 
SignedData construct [CMS].  The content is of type DCSInfo, which is 
indicated by the OID:

DCSInfo OBJECT IDENTIFIER  ::= { ??????  }

The data certification token MUST contain only the signature of the DCS.

DCSInfo ::= SEQUENCE  {
     dcsReqInfo                DCSReqInfo,
       --MUST be the same value as the dcsReqInfo field in DCSReqData
     messageImprint               MessageImprint,
       --if the data field in DCSReqData is MessageImprint, this
       --MUST contain that same value, otherwise it contains a hash of
       --the data field in DCSReqData using the hash algorithm
       --specified in the digestAlgorithm parameter of SignerInfo in 
       --the data certification token
     reqSignature                 SignerInfo OPTIONAL,
       --MUST be present if service field of dcsReqInfo is cpd
       --MUST be the same value as the signerInfo field in the data 
       --certification request
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         DCSTime, 
     chainCerts              [0]  SEQUENCE OF Certificate OPTIONAL, 
       --if present, MUST indicate the chain of trust that was used by 
       --the DCS to verify the signature or certificate in DCSReqData
     crls                    [2]  SEQUENCE OF CertificateList OPTIONAL, 
     policyReturnInfo        [3]  SEQUENCE OF PolicyReturnInfo OPTIONAL,
     extensions                   Extensions OPTIONAL  }

DCSTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

PolicyReturnInfo ::= SEQUENCE {
     policies                     SEQUENCE OF PolicyInformation,
     mappings                     SEQUENCE OF PolicyMappingsSyntax }

PKIStatusInfo is defined in Section 3.2.3 of [CMP].  If the PKIStatus 
field has value `waiting' (3), then this token is a receipt, as defined 
in Section 2.  Otherwise, the status field indicates whether or not the 
data certification request was fulfilled and, if not, failInfo indicates 
the reason it was rejected.  A valid data certification token will have 
a PKIStatus field with value `granted' (0).  For the purposes of the 
DCS, we define PKIFailureInfo for use in PKIStatusInfo.




Document Expiration:  December 4, 1998                            Page 7

PKIFailureInfo ::= BITSTRING  {
    badAlg           (0), 
      -- unrecognized or unsupported Algorithm Identifier
    badMessageCheck  (1), 
      -- integrity check failed (e.g., signature did not verify)
    badRequest       (2),
      -- transaction not permitted or supported
    badTime          (3),
      -- messageTime was not sufficiently close to the system time,
      -- as defined by local policy
    badCertId        (4), 
      -- no certificate could be found matching the provided criteria
    badDataFormat    (5),
      -- the data submitted has the wrong format
    wrong   (6),
      -- the  indicated in the request is different from the 
      -- one creating the response token
    incorrectData    (7),
      --the requester's data (i.e. signature) is incorrect 
      --(i.e. invalid)
    missingTimeStamp (8),
      -- when the timestamp is missing but should be there (by policy)
    certInvalid      (9),
      -- the certificate fails to validate against Section 6 of [CCP]
    certRevoked      (10),
      -- the certificate is revoked
    certExpired      (11),
      -- the certificate has expired
    certOnHold       (12),
      -- the certificate has been operationally suspended 
    certNotActive    (13)
      -- the certificate was not active at the given time
}

The statusString field of PKIStatusInfo can be used to include reason
text such as "CA's public key revoked".

CertId is defined in Section 7.5 of [CRMF].

The crls field (if present) SHOULD contain a sequence of certificate
 revocation lists that is sufficient to verify the chain of trust 
indicated in the chainCerts field.

The policyReturnInfo field indicates the policies and mappings that 
were processed during X.509 public key certificate path validation.
PolicyMappingsSyntax is defined in [CCP].
 
The reqSignature, chainCerts and crls fields are included as OPTIONAL.  
They SHOULD be present, when policy dictates, for use as supplementary 
evidence when resolving possible disputes.  Dispute resolution would 
most likely be handled by one or more humans, in an off-line 
environment, and is beyond the scope of this document.

6. Transports

There is no mandatory transport mechanism in this document.  All 

Document Expiration:  December 4, 1998                            Page 8

mechanisms are optional.

6.1. File Based Data Certification Server Protocol

A file containing a data certification message MUST contain only the DER 
encoding of one PKI message, i.e. there MUST be no extraneous header or 
trailer information in the file.

Such files can be used to transport data certification messages using 
for example, FTP.

6.2. Socket Based Data Certification Server Protocol

The socket based protocol for data certification messages is identical 
to that used in [CMP] Section 5.2 except that port 309 MUST be used.

6.3. Data Certification Server Protocol Using Email

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 4 via Internet mail. 

A simple MIME object is specified as follows.

   Content-Type: application/dcs
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Data Certification Server message, base64-
encoded>>

This MIME object can be sent and received using MIME processing engines 
and provides a simple Internet mail transport for Data Certification 
Server messages.

6.4. Data Certification Server Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via the HyperText 
Transfer Protocol.

A simple MIME object is specified as follows.

   Content-Type: application/dcs

   <<the ASN.1 DER-encoded Data Certification Server message>>

This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Data Certification Server messages.

7.  Security Considerations

This entire document discusses security considerations.

When designing a data certification service, the following 
considerations have been identified that have an impact upon the 
validity or "trust" in the data certification token.

Document Expiration:  December 4, 1998                            Page 9

     1. The enclosed public key certificate is revoked or the signer's 
        key is compromised and the corresponding public key certificate 
        is revoked before the Data Certification Server acts upon the 
        request. The Data Certification Server is REQUIRED to validate 
        appropriate information within the request before it 
        constructs the data certification token.  It is therefore 
        mandated that the DCS have access to current information 
        regarding public key certificate status before it creates the 
        token.  In this situation, the certification process would 
        produce an error.
     2. The enclosed public key certificate is revoked or the signer's 
        key is compromised and the corresponding certificate is revoked 
        after the Data Certification Server acts upon the request. This 
        is not a concern to the DCS once the Data Certification Server 
        has constructed the token, as long as the compromise date in the 
        CRL is not before the time of certification.  If it is, this 
        situation would have to be handled by off-line, possibly human-
        aided, means specific to the situation at hand.
     3. The Data Certification Server's private key is compromised and 
        the corresponding certificate is revoked.  In this case, any 
        token signed by the Data Certification Server cannot be trusted.  
        For this reason, it is imperative that the Data Certification 
        Server's key be guarded with proper security and controls in 
        order to minimize the possibility of compromise.  Nevertheless, 
        in case the private key does become compromised, an audit trail 
        of all the tokens generated by the DCS SHOULD be kept as a means 
        to help discriminate between genuine and false tokens.  
     4. The DCS signing key MUST be of a sufficient length to allow for 
        a sufficiently long lifetime.  Even if this is done, the key 
        will have a finite lifetime.  Thus, any token signed by the DCS 
        SHOULD be time stamped (if authentic copies of old CRLs 
        are available) or certified again (if they aren't) at a later 
        date to renew the trust that exists in the DCS's signature.  
        Data certification tokens could also be kept with an Evidence 
        Recording Authority [ISONR] to maintain this trust.
     5. When there is a reason to believe that the DCS can no longer
        be trusted, its certificate MUST be revoked and placed on the 
        appropriate CRL.  Thus, at any future time the tokens signed 
        with the corresponding key will not be trusted.
     6. In certain circumstances, a DCS may not be able to produce a 
        valid response to a request (for example, if it is unable to 
        compute signatures for a period of time).  In these situations   
        the DCS MUST wait until it is again able to produce a valid  
        response and then respond to the request.  Under no 
        circumstances shall a DCS produce an unsigned response to a 
        request.
     7. This protocol assumes that the CA has conducted a test for proof 
        of possession for each user's signing private key.  If this is 
        not the case, or when additional assurances are required, the 
        certificate of the requester (resp. DCS) SHALL be included in 
        the encapsulation of the data certification request (resp. data 
        certification token) as an authenticated attribute.

8. Patent Information

The following United States Patents related to data certification 

Document Expiration:  December 4, 1998                           Page 10

servers (notaries), listed in chronological order,  are known by the 
authors to exist at this time.  This may not be an exhaustive list.  
Other patents may exist or be issued at any time.  Implementers of this 
protocol SHOULD perform their own patent search and determine whether or 
not any encumberences exist on their implementation.

# 4,309,569	Method of Providing Digital Signatures
(issued) January 5, 1982
(inventor) Ralph C. Merkle
(assignee) The Board of Trustees of the Leland Stanford Junior 
University

# 5,001,752	Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M. Fischer

# 5,022,080	Electronic Notary
(issued) June 4, 1991
(inventors) Robert T. Durst, Kevin D. Hunter

# 5,136,643	Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M. Fischer
(Note: This is a continuation of patent # 5,001,752.)

# 5,136,646	Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,136,647	Method for Secure Time-Stamping of Digital Documents
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,373,561	Method of Extending the Validity of a Cryptographic 
Certificate
(issued) December 13, 1994
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,422,95 Personal Date/Time Notary Device
(issued) June 6, 1995
(inventor) Addison M. Fischer

9. References

[TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Time Stamp 
Protocols," draft-adams-time-stamp-0X.txt, 1998 (work in progress).

[CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure, 
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1998 (work in progress).




Document Expiration:  December 4, 1998                           Page 11

 [CRMF] C. Adams, "Internet Public Key Infrastructure, Certificate
Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 (work in
progress).

[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1998 (work in progress).

 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.  
Non-Repudiation Framework.

[RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.

10. Authors' Addresses

Carlisle Adams                     Robert Zuccherato
Entrust Technologies               Entrust Technologies
750 Heron Road                     750 Heron Road
Ottawa, Ontario                    Ottawa, Ontario
K1V 1A7                            K1V 1A7
CANADA                             CANADA
cadams@entrust.com                 robert.zuccherato@entrust.com































Document Expiration:  December 4, 1998                           Page 12

APPENDIX A - Storage of Data and Token

A data certification token is useless without the data to which it 
applies.  For this reason tokens and their related data MUST be securely 
stored together.  The change of a single bit in either the data or the 
token renders the entire certification process for that data 
meaningless.  Storage of tokens and data in a secure (e.g., tamper 
proof) environment is strongly RECOMMENDED.

When data and data certification tokens are stored together, the 
following ASN.1 data type MAY be used.

DataAndToken ::= SEQUENCE  {
     message                      Message,
     dcsToken                  DCSInfo  }

Note that this object does not need to be signed, as the data 
certification token already verifies the integrity of the data in the 
message.  Any supplementary information whose integrity needs to be 
protected SHOULD be part of the message or token.



APPENDIX B - Extending the Life of a Signature

We present an example of a possible use of this data certification 
service.  It produces a stand-alone token that can be used to extend the 
life of a signature.  This example assumes that we have total trust in 
the Data Certification Server.

Signature algorithms and keys have a definite lifetime.  Therefore, 
signatures have a definite lifetime.  The Data Certification Server can 
be used to extend the lifetime of a signature.

In order to extend the lifetime of a signature in this way, the 
following technique MAY be used.

A) The signature needs to be certified.

     1) The signed message is presented to the Data Certification Server 
        in the data field of DCSReqInfo under service type cs and an 
        appropriate policy.

     2) The Data Certification Server verifies that the signature and 
        verification key are valid at that time by checking expiry dates 
        and status information, and returns a data certification token.

B)  The certified signature MUST be verified.

     1) The signature of the Data Certification Server in data 
        certification token SHALL be verified using the Data 
        Certification Server's valid verification key.

In this situation the signer's signing key (and therefore, its 
signature) is only valid until some specified time T1.  The DCS's 
signing key (and therefore, its signature) is valid until some specified

Document Expiration:  December 4, 1998                           Page 13

time T2 that is (usually) after time T1.  Without certification, the 
signer's signature would only be valid until time T1.  With 
certification, the signer's signature remains valid until time T2,
regardless of subsequent revocation or expiry at time T1.

If the signature of the DCS is valid, the trust we have in the DCS 
allows us to conclude that the original signature on the data was valid 
at the time included in the dcsInfo field of the data certification 
token.  



APPENDIX C - Verifying the Status of a Public Key Certificate

We now present an example of how to produce a stand-alone token that can 
be used to confirm the revocation status of a public key certificate.

CRLs and ARLs are updated according to a schedule at regular intervals.
For some purposes, the granularity provided by the CRLs and ARLs is not
fine enough.  Up-to-date revocation status may be needed before the next
CRL or ARL update.  Since the DCS MUST have access to current 
information regarding public key certificate status, it can be used to 
verify the revocation status of a certificate in this situation.

In order to produce such a token, the following technique MAY be used.

A) The public key certificate needs to be certified.

     1) The certificate is presented to the Data Certification Server in 
        the data field of DCSReqInfo under service type cpkc and an 
        appropriate policy.

     2) The Data Certification Server verifies that the public key  
        certificate is valid and that it hasn't been revoked and then 
        returns a data certification token.

B)  The data certification token MUST be verified.

     1) The signature of the Data Certification Server in the data 
        certification token SHALL be verified using the Data 
        Certification Server's valid verification key.

This data certification token can now be used when verifying signatures 
using the key contained in the public key certificate.  This service 
provided by the DCS can be thought of as a supplement to the usual 
method of checking revocation status.











Document Expiration:  December 4, 1998                           Page 14