idnits 2.17.1 draft-adams-dcs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([ISONR], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 32 has weird spacing: '...Server is a T...' == Line 102 has weird spacing: '... Server is RE...' == Line 141 has weird spacing: '...Server perfor...' == Line 178 has weird spacing: '... Server would...' == Line 242 has weird spacing: '... Server will ...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 1998) is 9457 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 369 -- Looks like a reference, but probably isn't: '1' on line 268 -- Looks like a reference, but probably isn't: '2' on line 372 -- Looks like a reference, but probably isn't: '3' on line 373 -- No information found for draft-adams-time-stamp-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TSA' -- No information found for draft-ietf-pkix-ipki3cmp-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CMP' -- No information found for draft-ietf-pkix-crmf-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CRMF' -- No information found for draft-ietf-pkix-ipki-part1-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CCP' == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISONR' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 C. Adams(Entrust Technologies) 2 Internet Draft R. Zuccherato(Entrust Technologies) 3 expires in six months June 4, 1998 5 Data Certification Server Protocols 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 This document describes a general data certification service and the 31 protocols to be used when communicating with it. The Data Certification 32 Server is a Trusted Third Party (TTP) that can be used as one component 33 in building reliable non-repudiation services (see [ISONR]). Useful 34 Data Certification Server responsibilities in a PKI are to validate 35 signatures and to provide up-to-date information regarding the status of 36 public key certificates. We give examples of how to use the Data 37 Certification Server to extend the lifetime of a signature beyond key 38 expiry or revocation and to query the Data Certification Server 39 regarding the status of a public key certificate. 41 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 42 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 43 'OPTIONAL' in this document are to be interpreted as described in 44 RFC 2119 [RFC2119]. 46 1. Introduction 48 A Data Certification Server (DCS) is a Trusted Third Party that verifies 49 the correctness of specific data submitted to it. The Data 50 Certification Server provides the data certification service in order 51 that non-repudiation evidence may be constructed relating to the 52 validity and correctness of an entity's claim to possess data, the 53 validity and revocation status of an entity's public key certificate 54 and/or the validity and correctness of another entity's signature. When 55 certifying possession of data or another entity's signature, the DCS 57 verifies the mathematical correctness of the actual signature value 58 contained in the request and also checks the full certification path 59 from the signing entity to a trusted point (e.g., the DCS's CA, or the 60 root CA in a hierarchy). The DCS MAY be able to rely on all relevant 61 CRLs and ARLs, or the DCS MAY need to supplement this with access to 62 more current status information from the CA. It then includes a trusted 63 time and creates a data certification token. (See Appendix B.) 65 When certifying a public key certificate, the DCS verifies that the 66 certificate included in the request is a valid certificate and 67 determines its revocation status at a specified time. Again, it checks 68 the full certification path from the certificate signing entity to a 69 trusted point. The DCS MAY be able to rely on all relevant CRLs and 70 ARLs, or the DCS MAY need to supplement this with access to more current 71 status information from the CA. It includes this information, along 72 with a trusted time, to create a Data Certification Token. (See 73 Appendix C.) 75 The presence of a data certification token supports non-repudiation in 76 two ways. It provides evidence that a signature or public key 77 certificate was valid at thetime indicated in the token. The token can 78 be used even after the corresponding public key certificate expires and 79 its revocation information is no longer available on CRLs (for example). 80 The production of a data certification token in response to a signed 81 request for certification of another signature or public key certificate 82 also provides evidence that due diligence was performed by the requester 83 in validating the signature or public key certificate. 85 It is not recommended that the DCS be used as a substitute for normal 86 public keycertificate revocation checking (e.g. CRLs, OCSP) in large 87 environments, due to concerns about the scalability of this protocol. 88 It should only be used to support non-repudiation or to supplement more 89 traditional revocation services when more timely information is 90 required. 92 In all cases, the trust that PKI entities have in the Data Certification 93 Server is transferred to the contents of the data certification token 94 (just as trust in a CA is transferred to the public key certificates 95 that it issues). As a particular example, a data certification token 96 pertaining to a signature may be useful for extending the life of that 97 signature beyond the expiry or subsequent revocation of its 98 corresponding verification certificate. 100 2. Requirements of the Data Certification Server 102 The Data Certification Server is REQUIRED to: 104 1. verify the correctness of the enclosed digital signature using 105 all appropriate status information and public key certificates 106 and produce a signed data certification token attesting to the 107 validity of the signature, if asked by the requester. 108 2. verify the validity (according to [CCP]) of the enclosed public 109 key certificate and its revocation status at the specified time 110 using all appropriate status information and public key 111 certificates and produce a signed data certification token 112 attesting to the validity and revocation status of the public 114 key certificate, if asked by the requester. 115 3. include a monotonically incrementing value of the time of day 116 or a time stamp token into its data certification token. 117 4. include within each signed data certification token an 118 identifier to uniquely determine the trust and validation policy 119 used for this signature. 120 5. sign each data certification token using a key generated 121 exclusively for this purpose and have this property of the key 122 indicated on the corresponding public key certificate. 123 6. indicate in the token whether or not the signature or public key 124 certificate verified, and if not, the reason the verification 125 failed. 126 7. provide a signed receipt (i.e., in the form of an appropriately 127 defined data certification token) to the requester, where 128 appropriate, as defined by policy. 130 3. Data Certification Server Transactions 132 As the first transaction of this mechanism, the requesting entity 133 requests a certification by sending a request (which is or includes a 134 data certification request, as defined below), including the data for 135 which validity and/or possession is to be certified, to the Data 136 Certification Server. Upon receiving the request, the Data 137 Certification Server reviews and checks the validity of the request. A 138 valid request is of the form described in Section 5 of this document, 139 can be properly decoded, and is from a supported Data Certification 140 Server subscriber. If the request is valid, the Data Certification 141 Server performs the certification and sends a response (which is or 142 includes a data certification token, as defined below) to the requesting 143 entity. Otherwise, the Data Certification Server returns an error 144 message (i.e., in the form of an appropriately defined data 145 certification token). 147 Upon receiving the token, the requesting entity verifies its validity. 148 The requester SHOULD verify that it contains the correct time, the 149 correct name for the DCS, the correct data imprint, a valid signature, 150 and satisfactory status, service and policy fields. Since the DCS's 151 certificate may have been revoked, the appropriate status information 152 SHOULD be checked to verify that the certificate is still valid. The 153 token can now be used to authenticate the correctness or possession of 154 the corresponding data. 156 4. Identification of the DCS 158 The DCS MUST sign all data certification messages with a key reserved 159 specifically for that purpose. The corresponding certificate MUST 160 contain the extended key usage field extension as defined in [CCP] 161 Section 4.2.1.14 with KeyPurposeID having value id-kp-dcs. This 162 extension MUST be critical. 164 id-kp-dcs OBJECT IDENTIFIER ::= {id-kp ??} 165 -- Certifying the validity of certain information. Key usage bits 166 -- that may be consistent: digitalSignature, nonRepudiation 168 5. Request and Token Formats 170 The ServiceType type indicates which type of Data Certification Server 171 Service is required. 173 ServiceType ::= INTEGER { cpd(1), cs(2), cpkc(3) } 175 The value cpd (Certify Possession of Data) is used when only the 176 signature on the data certification request (i.e., possession of the 177 data in the request) is to be verified. In this case the Data 178 Certification Server would be merely providing evidence that the 179 requester possessed the data in the request and a valid signature key at 180 the time indicated. This is really an extension of the Time Stamp 181 Authority [TSA] in that we are given the additional assurance about the 182 validity of the signature, as well as the time before which it was 183 applied. The value cs (Certify Signature) is used when another entity's 184 signature is to be validated. The resulting token can then be used to 185 support non-repudiation services or to allow use of the signature beyond 186 public key certificate revocation or expiry. 188 The value cpkc (Certify Public Key Certificate) is used when the 189 validity and revocation status of the public key certificates included 190 in the request are to be verified. This service can be used to 191 supplement the use of CRLs when timely information regarding a 192 certificate's revocation state is required (e.g. high value funds 193 transfer or the compromise of a highly sensitive key) or when evidence 194 supporting non-repudiation is required. A given DCS MAY support any 195 subset of the above services. 197 Upon receiving a signed request for either service cs or cpkc the DCS 198 MUSTalso verify the signature on the request as is done for the cpd 199 service. Note however, that signed requests for the cs or cpkc service 200 are not required. 202 A data certification request is as follows. It is encapsulated as a 203 SignedData construct [CMS]. The content is of type DCSReqData, which is 204 indicated by the OID: 206 DCSReqData OBJECT IDENTIFIER ::= { ?????? } 208 The data certification request MUST either be unsigned or contain only 209 the signature of the requester. 211 The data and information that will be certified are contained in the 212 content field of the SignedData content type. 214 DCSReqData ::= SEQUENCE { 215 dcsReqInfo DCSReqInfo, 216 data Data 217 --the data to be certified 218 --this field MUST be of type Message if the service type is cs 219 --and of type SEQUENCE OF Certificate if the service type is cpkc 220 } 222 The dcsReqInfo field contains information pertaining to the data 223 certification request. 225 DCSReqInfo ::= SEQUENCE { 226 version Integer { v1(0) }, 227 service ServiceType, 228 requester GeneralName OPTIONAL, 229 --MUST be present if the service field is cpd 230 --MUST match the identity (subjectName or subjectAltName 231 --extension) for the corresponding signing certificate 232 reqPolicy PolicyInformation OPTIONAL, 233 dcs GeneralName OPTIONAL, 234 nonce Integer, 235 reqTime ReqTime OPTIONAL, 236 extensions Extensions OPTIONAL } 238 ReqTime ::= CHOICE { 239 genTime GeneralizedTime, 240 timeStampToken TimeStampToken } 242 In situations where the Data Certification Server will verify the 243 identity of the requester (i.e., when the service field is cpd), the 244 data certification request MUST be signed by the requester using the 245 signerInfos field. 247 Similarly, in situations where the Data Certification Server will 248 certify the time included in the request (i.e., when stipulated by the 249 policy of the Data Certification Server ), the data certification 250 request MUST include the reqTime field in DCSReqInfo. Thus, when 251 verifying a public key certificate, the presence of this field indicates 252 the time for which the validity and revocation status of the certificate 253 SHOULD be reported. If this field is not present, the current time is 254 assumed. TimeStampToken is defined in Sect 2.4 of [TSA]. 256 PolicyInformation is defined in Section 4.2.1.5 of [CCP]. The 257 reqPolicy field SHOULD indicate the policy under which the certification 258 is requested. This field MUST be checked by the DCS to verify agreement 259 with its own policy. The absence of this field indicates that any 260 policy is acceptable. 262 The Data type is defined to be either the message itself, a hash of 263 the message (this allows a signature indicating possession of private 264 data to be certified) or the certificate to be verified. 266 Data ::= CHOICE { 267 message [0] Message, 268 messageimprint [1] MessageImprint, 269 certs [2] SEQUENCE SIZE (1..MAX) OF 270 TargetandChain } 272 In order to specify the format (i.e. the type) of the message so that 273 it may be parsed and understood by the DCS or any verifying entity, we 274 define the Message data type. 276 Message ::= SEQUENCE { 277 format MESSAGECLASS.&id, --objid 278 rawdata MESSAGECLASS.&Type --open type 279 } 281 MESSAGECLASS ::= CLASS { 282 &id OBJECT IDENTIFIER UNIQUE, 283 &Type } 284 WITH SYNTAX { &Type IDENTIFIED BY &id } 286 Possible message types include id-data and id-signedData [CMS]. 288 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 289 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 291 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 292 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 294 In particular, if the message type is id-signedData (or any other 295 message type that allows more than one signature) and more than one 296 SignerInfo (or signature) is present under service type cs, the DCS 297 MUST verify all signatures present. In this case the failure of any 298 one signature to verify will result in the failure of the entire 299 certification. 301 If the requester prefers to send a hash of the message instead, the 302 MessageImprint data type SHOULD be used. 304 MessageImprint ::= SEQUENCE { 305 hashAlgorithm AlgorithmIdentifier, 306 hashedMessage OCTET STRING } 308 The hash algorithm indicated in the hashAlgorithm field SHOULD be a 309 "strong" hash algorithm (that is, it SHOULD be one-way and collision 310 resistant). It is up to the Data Certification Server to decide whether 311 or not the given hash algorithm is sufficiently "strong" (based on the 312 current state of knowledge in cryptanalysis and the current state of the 313 art in computational resources, for example). 315 The hashedMessage field SHOULD contain the hash of the DER encoding of 316 the message expressed as a Message data type. The hash is represented 317 as an OCTET STRING. 319 TargetandChain ::= SEQUENCE { 320 target Certificate, 321 chain SEQUENCE SIZE (1..MAX) OF Certificate 322 OPTIONAL, 323 pathProcInput PathProcInput OPTIONAL } 325 PathProcInput ::= SEQUENCE { 326 acceptablePolicySet CertPolicySet, 327 inhibitPolicyMapping BOOLEAN DEFAULT FALSE, 328 explicitPolicyReqd BOOLEAN DEFAULT FALSE } 330 The certs field SHOULD contain the certificate to be certified. Each 331 certificate SHALL be included in a separate instance of TargetandChain. 332 The target field SHALL contain the cert to be verified and the chain 333 field, if present, MUST indicate the chain of trust to be used when 334 certifying the certificate. The pathProcInput field, if present, SHOULD 335 indicate the acceptable policy set and initial settings for 336 explicit-policy-indicator and inhibit-policy-mapping indicators to be 338 used in X.509 public key certificate path validation (see [CCP]). 340 Extensions are described in Section 4.2 of [CCP]. The criticality of 341 the extensions MUST be honoured by conformant DCSs and clients (e.g. 342 requests and responses containing critical extensions which are not 343 understood MUST be rejected). 345 A data certification token is as follows. It is encapsulated as a 346 SignedData construct [CMS]. The content is of type DCSInfo, which is 347 indicated by the OID: 349 DCSInfo OBJECT IDENTIFIER ::= { ?????? } 351 The data certification token MUST contain only the signature of the DCS. 353 DCSInfo ::= SEQUENCE { 354 dcsReqInfo DCSReqInfo, 355 --MUST be the same value as the dcsReqInfo field in DCSReqData 356 messageImprint MessageImprint, 357 --if the data field in DCSReqData is MessageImprint, this 358 --MUST contain that same value, otherwise it contains a hash of 359 --the data field in DCSReqData using the hash algorithm 360 --specified in the digestAlgorithm parameter of SignerInfo in 361 --the data certification token 362 reqSignature SignerInfo OPTIONAL, 363 --MUST be present if service field of dcsReqInfo is cpd 364 --MUST be the same value as the signerInfo field in the data 365 --certification request 366 policy PolicyInformation, 367 status PKIStatusInfo, 368 time DCSTime, 369 chainCerts [0] SEQUENCE OF Certificate OPTIONAL, 370 --if present, MUST indicate the chain of trust that was used by 371 --the DCS to verify the signature or certificate in DCSReqData 372 crls [2] SEQUENCE OF CertificateList OPTIONAL, 373 policyReturnInfo [3] SEQUENCE OF PolicyReturnInfo OPTIONAL, 374 extensions Extensions OPTIONAL } 376 DCSTime ::= CHOICE { 377 genTime GeneralizedTime, 378 timeStampToken TimeStampToken } 380 PolicyReturnInfo ::= SEQUENCE { 381 policies SEQUENCE OF PolicyInformation, 382 mappings SEQUENCE OF PolicyMappingsSyntax } 384 PKIStatusInfo is defined in Section 3.2.3 of [CMP]. If the PKIStatus 385 field has value `waiting' (3), then this token is a receipt, as defined 386 in Section 2. Otherwise, the status field indicates whether or not the 387 data certification request was fulfilled and, if not, failInfo indicates 388 the reason it was rejected. A valid data certification token will have 389 a PKIStatus field with value `granted' (0). For the purposes of the 390 DCS, we define PKIFailureInfo for use in PKIStatusInfo. 392 PKIFailureInfo ::= BITSTRING { 393 badAlg (0), 394 -- unrecognized or unsupported Algorithm Identifier 395 badMessageCheck (1), 396 -- integrity check failed (e.g., signature did not verify) 397 badRequest (2), 398 -- transaction not permitted or supported 399 badTime (3), 400 -- messageTime was not sufficiently close to the system time, 401 -- as defined by local policy 402 badCertId (4), 403 -- no certificate could be found matching the provided criteria 404 badDataFormat (5), 405 -- the data submitted has the wrong format 406 wrong (6), 407 -- the indicated in the request is different from the 408 -- one creating the response token 409 incorrectData (7), 410 --the requester's data (i.e. signature) is incorrect 411 --(i.e. invalid) 412 missingTimeStamp (8), 413 -- when the timestamp is missing but should be there (by policy) 414 certInvalid (9), 415 -- the certificate fails to validate against Section 6 of [CCP] 416 certRevoked (10), 417 -- the certificate is revoked 418 certExpired (11), 419 -- the certificate has expired 420 certOnHold (12), 421 -- the certificate has been operationally suspended 422 certNotActive (13) 423 -- the certificate was not active at the given time 424 } 426 The statusString field of PKIStatusInfo can be used to include reason 427 text such as "CA's public key revoked". 429 CertId is defined in Section 7.5 of [CRMF]. 431 The crls field (if present) SHOULD contain a sequence of certificate 432 revocation lists that is sufficient to verify the chain of trust 433 indicated in the chainCerts field. 435 The policyReturnInfo field indicates the policies and mappings that 436 were processed during X.509 public key certificate path validation. 437 PolicyMappingsSyntax is defined in [CCP]. 439 The reqSignature, chainCerts and crls fields are included as OPTIONAL. 440 They SHOULD be present, when policy dictates, for use as supplementary 441 evidence when resolving possible disputes. Dispute resolution would 442 most likely be handled by one or more humans, in an off-line 443 environment, and is beyond the scope of this document. 445 6. Transports 447 There is no mandatory transport mechanism in this document. All 449 mechanisms are optional. 451 6.1. File Based Data Certification Server Protocol 453 A file containing a data certification message MUST contain only the DER 454 encoding of one PKI message, i.e. there MUST be no extraneous header or 455 trailer information in the file. 457 Such files can be used to transport data certification messages using 458 for example, FTP. 460 6.2. Socket Based Data Certification Server Protocol 462 The socket based protocol for data certification messages is identical 463 to that used in [CMP] Section 5.2 except that port 309 MUST be used. 465 6.3. Data Certification Server Protocol Using Email 467 This section specifies a means for conveying ASN.1-encoded messages 468 for the protocol exchanges described in Section 4 via Internet mail. 470 A simple MIME object is specified as follows. 472 Content-Type: application/dcs 473 Content-Transfer-Encoding: base64 475 <> 478 This MIME object can be sent and received using MIME processing engines 479 and provides a simple Internet mail transport for Data Certification 480 Server messages. 482 6.4. Data Certification Server Protocol via HTTP 484 This subsection specifies a means for conveying ASN.1-encoded messages 485 for the protocol exchanges described in Section 4 via the HyperText 486 Transfer Protocol. 488 A simple MIME object is specified as follows. 490 Content-Type: application/dcs 492 <> 494 This MIME object can be sent and received using common HTTP processing 495 engines over WWW links and provides a simple browser-server transport 496 for Data Certification Server messages. 498 7. Security Considerations 500 This entire document discusses security considerations. 502 When designing a data certification service, the following 503 considerations have been identified that have an impact upon the 504 validity or "trust" in the data certification token. 506 1. The enclosed public key certificate is revoked or the signer's 507 key is compromised and the corresponding public key certificate 508 is revoked before the Data Certification Server acts upon the 509 request. The Data Certification Server is REQUIRED to validate 510 appropriate information within the request before it 511 constructs the data certification token. It is therefore 512 mandated that the DCS have access to current information 513 regarding public key certificate status before it creates the 514 token. In this situation, the certification process would 515 produce an error. 516 2. The enclosed public key certificate is revoked or the signer's 517 key is compromised and the corresponding certificate is revoked 518 after the Data Certification Server acts upon the request. This 519 is not a concern to the DCS once the Data Certification Server 520 has constructed the token, as long as the compromise date in the 521 CRL is not before the time of certification. If it is, this 522 situation would have to be handled by off-line, possibly human- 523 aided, means specific to the situation at hand. 524 3. The Data Certification Server's private key is compromised and 525 the corresponding certificate is revoked. In this case, any 526 token signed by the Data Certification Server cannot be trusted. 527 For this reason, it is imperative that the Data Certification 528 Server's key be guarded with proper security and controls in 529 order to minimize the possibility of compromise. Nevertheless, 530 in case the private key does become compromised, an audit trail 531 of all the tokens generated by the DCS SHOULD be kept as a means 532 to help discriminate between genuine and false tokens. 533 4. The DCS signing key MUST be of a sufficient length to allow for 534 a sufficiently long lifetime. Even if this is done, the key 535 will have a finite lifetime. Thus, any token signed by the DCS 536 SHOULD be time stamped (if authentic copies of old CRLs 537 are available) or certified again (if they aren't) at a later 538 date to renew the trust that exists in the DCS's signature. 539 Data certification tokens could also be kept with an Evidence 540 Recording Authority [ISONR] to maintain this trust. 541 5. When there is a reason to believe that the DCS can no longer 542 be trusted, its certificate MUST be revoked and placed on the 543 appropriate CRL. Thus, at any future time the tokens signed 544 with the corresponding key will not be trusted. 545 6. In certain circumstances, a DCS may not be able to produce a 546 valid response to a request (for example, if it is unable to 547 compute signatures for a period of time). In these situations 548 the DCS MUST wait until it is again able to produce a valid 549 response and then respond to the request. Under no 550 circumstances shall a DCS produce an unsigned response to a 551 request. 552 7. This protocol assumes that the CA has conducted a test for proof 553 of possession for each user's signing private key. If this is 554 not the case, or when additional assurances are required, the 555 certificate of the requester (resp. DCS) SHALL be included in 556 the encapsulation of the data certification request (resp. data 557 certification token) as an authenticated attribute. 559 8. Patent Information 561 The following United States Patents related to data certification 563 servers (notaries), listed in chronological order, are known by the 564 authors to exist at this time. This may not be an exhaustive list. 565 Other patents may exist or be issued at any time. Implementers of this 566 protocol SHOULD perform their own patent search and determine whether or 567 not any encumberences exist on their implementation. 569 # 4,309,569 Method of Providing Digital Signatures 570 (issued) January 5, 1982 571 (inventor) Ralph C. Merkle 572 (assignee) The Board of Trustees of the Leland Stanford Junior 573 University 575 # 5,001,752 Public/Key Date-Time Notary Facility 576 (issued) March 19, 1991 577 (inventor) Addison M. Fischer 579 # 5,022,080 Electronic Notary 580 (issued) June 4, 1991 581 (inventors) Robert T. Durst, Kevin D. Hunter 583 # 5,136,643 Public/Key Date-Time Notary Facility 584 (issued) August 4, 1992 585 (inventor) Addison M. Fischer 586 (Note: This is a continuation of patent # 5,001,752.) 588 # 5,136,646 Digital Document Time-Stamping with Catenate Certificate 589 (issued) August 4, 1992 590 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 591 (assignee) Bell Communications Research, Inc., 593 # 5,136,647 Method for Secure Time-Stamping of Digital Documents 594 (issued) August 4, 1992 595 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 596 (assignee) Bell Communications Research, Inc., 598 # 5,373,561 Method of Extending the Validity of a Cryptographic 599 Certificate 600 (issued) December 13, 1994 601 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 602 (assignee) Bell Communications Research, Inc., 604 # 5,422,95 Personal Date/Time Notary Device 605 (issued) June 6, 1995 606 (inventor) Addison M. Fischer 608 9. References 610 [TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Time Stamp 611 Protocols," draft-adams-time-stamp-0X.txt, 1998 (work in progress). 613 [CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure, 614 Certificate Management Protocols," draft-ietf-pkix-ipki3cmp- 615 0X.txt, 1998 (work in progress). 617 [CRMF] C. Adams, "Internet Public Key Infrastructure, Certificate 618 Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 (work in 619 progress). 621 [CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key 622 Infrastructure, X.509 Certificate and CRL Profile," draft- 623 ietf-pkix-ipki-part1-0X.txt, 1998 (work in progress). 625 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms- 626 02.txt, 1998 (work in progress). 628 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 629 Non-Repudiation Framework. 631 [RFC2119] Key works for use in RFCs to Indicate Requirement Levels, 632 S. Bradner, RFC 2119, March 1997. 634 10. Authors' Addresses 636 Carlisle Adams Robert Zuccherato 637 Entrust Technologies Entrust Technologies 638 750 Heron Road 750 Heron Road 639 Ottawa, Ontario Ottawa, Ontario 640 K1V 1A7 K1V 1A7 641 CANADA CANADA 642 cadams@entrust.com robert.zuccherato@entrust.com 644 APPENDIX A - Storage of Data and Token 646 A data certification token is useless without the data to which it 647 applies. For this reason tokens and their related data MUST be securely 648 stored together. The change of a single bit in either the data or the 649 token renders the entire certification process for that data 650 meaningless. Storage of tokens and data in a secure (e.g., tamper 651 proof) environment is strongly RECOMMENDED. 653 When data and data certification tokens are stored together, the 654 following ASN.1 data type MAY be used. 656 DataAndToken ::= SEQUENCE { 657 message Message, 658 dcsToken DCSInfo } 660 Note that this object does not need to be signed, as the data 661 certification token already verifies the integrity of the data in the 662 message. Any supplementary information whose integrity needs to be 663 protected SHOULD be part of the message or token. 665 APPENDIX B - Extending the Life of a Signature 667 We present an example of a possible use of this data certification 668 service. It produces a stand-alone token that can be used to extend the 669 life of a signature. This example assumes that we have total trust in 670 the Data Certification Server. 672 Signature algorithms and keys have a definite lifetime. Therefore, 673 signatures have a definite lifetime. The Data Certification Server can 674 be used to extend the lifetime of a signature. 676 In order to extend the lifetime of a signature in this way, the 677 following technique MAY be used. 679 A) The signature needs to be certified. 681 1) The signed message is presented to the Data Certification Server 682 in the data field of DCSReqInfo under service type cs and an 683 appropriate policy. 685 2) The Data Certification Server verifies that the signature and 686 verification key are valid at that time by checking expiry dates 687 and status information, and returns a data certification token. 689 B) The certified signature MUST be verified. 691 1) The signature of the Data Certification Server in data 692 certification token SHALL be verified using the Data 693 Certification Server's valid verification key. 695 In this situation the signer's signing key (and therefore, its 696 signature) is only valid until some specified time T1. The DCS's 697 signing key (and therefore, its signature) is valid until some specified 699 time T2 that is (usually) after time T1. Without certification, the 700 signer's signature would only be valid until time T1. With 701 certification, the signer's signature remains valid until time T2, 702 regardless of subsequent revocation or expiry at time T1. 704 If the signature of the DCS is valid, the trust we have in the DCS 705 allows us to conclude that the original signature on the data was valid 706 at the time included in the dcsInfo field of the data certification 707 token. 709 APPENDIX C - Verifying the Status of a Public Key Certificate 711 We now present an example of how to produce a stand-alone token that can 712 be used to confirm the revocation status of a public key certificate. 714 CRLs and ARLs are updated according to a schedule at regular intervals. 715 For some purposes, the granularity provided by the CRLs and ARLs is not 716 fine enough. Up-to-date revocation status may be needed before the next 717 CRL or ARL update. Since the DCS MUST have access to current 718 information regarding public key certificate status, it can be used to 719 verify the revocation status of a certificate in this situation. 721 In order to produce such a token, the following technique MAY be used. 723 A) The public key certificate needs to be certified. 725 1) The certificate is presented to the Data Certification Server in 726 the data field of DCSReqInfo under service type cpkc and an 727 appropriate policy. 729 2) The Data Certification Server verifies that the public key 730 certificate is valid and that it hasn't been revoked and then 731 returns a data certification token. 733 B) The data certification token MUST be verified. 735 1) The signature of the Data Certification Server in the data 736 certification token SHALL be verified using the Data 737 Certification Server's valid verification key. 739 This data certification token can now be used when verifying signatures 740 using the key contained in the public key certificate. This service 741 provided by the DCS can be thought of as a supplement to the usual 742 method of checking revocation status.