idnits 2.17.1 draft-ietf-pkix-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-26) 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 13 longer pages, the longest (page 2) 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 31 has weird spacing: '...Server is a T...' == Line 140 has weird spacing: '...Server perfor...' == Line 177 has weird spacing: '... Server would...' == Line 249 has weird spacing: '... Server will ...' == Line 254 has weird spacing: '... Server will...' == (1 more instance...) -- 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 (September 23, 1998) is 9347 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 388 -- Looks like a reference, but probably isn't: '1' on line 275 -- Looks like a reference, but probably isn't: '2' on line 391 -- Looks like a reference, but probably isn't: '3' on line 393 -- No information found for draft-ietf-pkix-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-ipki-part1-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CCP' -- No information found for draft-ietf-smime-cms-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISONR' -- No information found for draft-ietf-pkix-crmf-0X - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CRMF' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Adams(Entrust Technologies) 2 PKIX Working Group R. Zuccherato(Entrust Technologies) 3 expires in six months September 23, 1998 5 Internet X.509 Public Key Infrastructure 6 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 learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes a general data certification service and the 30 protocols to be used when communicating with it. The Data Certification 31 Server is a Trusted Third Party (TTP) that can be used as one component 32 in building reliable non-repudiation services (see [ISONR]). Useful 33 Data Certification Server responsibilities in a PKI are to validate 34 signatures and to provide up-to-date information regarding the status of 35 public key certificates. We give examples of how to use the Data 36 Certification Server to extend the lifetime of a signature beyond key 37 expiry or revocation and to query the Data Certification Server 38 regarding the status of a public key certificate. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 41 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in 43 RFC 2119 [RFC2119]. 45 1. Introduction 47 A Data Certification Server (DCS) is a Trusted Third Party that verifies 48 the correctness of specific data submitted to it. The Data 49 Certification Server provides the data certification service in order 50 that non-repudiation evidence may be constructed relating to the 51 validity and correctness of an entity's claim to possess data, the 52 validity and revocation status of an entity's public key certificate 53 and/or the validity and correctness of another entity's signature. When 54 certifying possession of data or another entity's signature, the DCS 56 verifies the mathematical correctness of the actual signature value 57 contained in the request and also checks the full certification path 58 from the signing entity to a trusted point (e.g., the DCS's CA, or the 59 root CA in a hierarchy). The DCS MAY be able to rely on all relevant 60 CRLs and ARLs, or the DCS MAY need to supplement this with access to 61 more current status information from the CA. It then includes a trusted 62 time and creates a data certification token. (See Appendix B.) 64 When certifying a public key certificate, the DCS verifies that the 65 certificate included in the request is a valid certificate and 66 determines its revocation status at a specified time. Again, it checks 67 the full certification path from the certificate signing entity to a 68 trusted point. The DCS MAY be able to rely on all relevant CRLs and 69 ARLs, or the DCS MAY need to supplement this with access to more current 70 status information from the CA. It includes this information, along 71 with a trusted time, to create a Data Certification Token. (See 72 Appendix C.) 74 The presence of a data certification token supports non-repudiation in 75 two ways. It provides evidence that a signature or public key 76 certificate was valid at the time indicated in the token. The token can 77 be used even after the corresponding public key certificate expires and 78 its revocation information is no longer available on CRLs (for example). 79 The production of a data certification token in response to a signed 80 request for certification of another signature or public key certificate 81 also provides evidence that due diligence was performed by the requester 82 in validating the signature or public key certificate. 84 It is not recommended that the DCS be used as a substitute for normal 85 public key certificate revocation checking (e.g. CRLs, OCSP) in large 86 environments, due to concerns about the scalability of this protocol. 87 It should only be used to support non-repudiation or to supplement more 88 traditional revocation services when more timely information is 89 required. 91 In all cases, the trust that PKI entities have in the Data Certification 92 Server is transferred to the contents of the data certification token 93 (just as trust in a CA is transferred to the public key certificates 94 that it issues). As a particular example, a data certification token 95 pertaining to a signature may be useful for extending the life of that 96 signature beyond the expiry or subsequent revocation of its 97 corresponding verification certificate. 99 2. Requirements of the Data Certification Server 101 The Data Certification Server is REQUIRED to: 103 1. verify the correctness of the enclosed digital signature using 104 all appropriate status information and public key certificates 105 and produce a signed data certification token attesting to the 106 validity of the signature, if asked by the requester. 107 2. verify the validity (according to [CCP]) of the enclosed public 108 key certificate and its revocation status at the specified time 109 using all appropriate status information and public key 110 certificates and produce a signed data certification token 111 attesting to the validity and revocation status of the public 113 key certificate, if asked by the requester. 114 3. include a monotonically incrementing value of the time of day 115 or a time stamp token into its data certification token. 116 4. include within each signed data certification token an 117 identifier to uniquely determine the trust and validation policy 118 used for this signature. 119 5. sign each data certification token using a key generated 120 exclusively for this purpose and have this property of the key 121 indicated on the corresponding public key certificate. 122 6. indicate in the token whether or not the signature or public key 123 certificate verified, and if not, the reason the verification 124 failed. 125 7. provide a signed receipt (i.e., in the form of an appropriately 126 defined data certification token) to the requester, where 127 appropriate, as defined by policy. 129 3. Data Certification Server Transactions 131 As the first transaction of this mechanism, the requesting entity 132 requests a certification by sending a request (which is or includes a 133 data certification request, as defined below), including the data for 134 which validity and/or possession is to be certified, to the Data 135 Certification Server. Upon receiving the request, the Data 136 Certification Server reviews and checks the validity of the request. A 137 valid request is of the form described in Section 5 of this document, 138 can be properly decoded, and is from a supported Data Certification 139 Server subscriber. If the request is valid, the Data Certification 140 Server performs the certification and sends a response (which is or 141 includes a data certification token, as defined below) to the requesting 142 entity. Otherwise, the Data Certification Server returns an error 143 message (i.e., in the form of an appropriately defined data 144 certification token). 146 Upon receiving the token, the requesting entity verifies its validity. 147 The requester SHOULD verify that it contains the correct time, the 148 correct name for the DCS, the correct data imprint, a valid signature, 149 and satisfactory status, service and policy fields. Since the DCS's 150 certificate may have been revoked, the appropriate status information 151 SHOULD be checked to verify that the certificate is still valid. The 152 token can now be used to authenticate the correctness or possession of 153 the corresponding data. 155 4. Identification of the DCS 157 The DCS MUST sign all data certification messages with a key reserved 158 specifically for that purpose. The corresponding certificate MUST 159 contain the extended key usage field extension as defined in [CCP] 160 Section 4.2.1.14 with KeyPurposeID having value id-kp-dcs. This 161 extension MUST be critical. 163 id-kp-dcs OBJECT IDENTIFIER ::= {id-kp ??} 164 -- Certifying the validity of certain information. Key usage bits 165 -- that may be consistent: digitalSignature, nonRepudiation 167 5. Request and Token Formats 169 The ServiceType type indicates which type of Data Certification Server 170 service is required. 172 ServiceType ::= INTEGER { cpd(1), cs(2), cpkc(3) } 174 The value cpd (Certify Possession of Data) is used when only the 175 signature on the data certification request (i.e., possession of the 176 data in the request) is to be verified. In this case the Data 177 Certification Server would be merely providing evidence that the 178 requester possessed the data in the request and a valid signature key at 179 the time indicated. This is really an extension of the Time Stamp 180 Authority [TSA] in that we are given the additional assurance about the 181 validity of the signature, as well as the time before which it was 182 applied. The value cs (Certify Signature) is used when another entity's 183 signature is to be validated. The resulting token can then be used to 184 support non-repudiation services or to allow use of the signature beyond 185 public key certificate revocation or expiry. 187 The value cpkc (Certify Public Key Certificate) is used when the 188 validity and revocation status of the public key certificates included 189 in the request are to be verified. This service can be used to 190 supplement the use of CRLs when timely information regarding a 191 certificate's revocation state is required (e.g. high value funds 192 transfer or the compromise of a highly sensitive key) or when evidence 193 supporting non-repudiation is required. A given DCS MAY support any 194 subset of the above services. 196 Upon receiving a signed request for either service cs or cpkc the DCS 197 MUST also verify the signature on the request as is done for the cpd 198 service. Note however, that signed requests for the cs or cpkc service 199 are not required. 201 A data certification request is as follows. It is encapsulated as a 202 SignedData construct [CMS]. The content is of type DCSReqData. 204 DCSRequest ContentInfo ::= SEQUENCE { 205 contentType OBJECT IDENTIFIER, 206 --{pkcs-7 2}, SignedData 207 content [0] SEQUENCE { 208 version INTEGER, 209 digestAlgorithms AlgorithmIdentifier, 210 contentInfo SEQUENCE { 211 contentType OBJECT IDENTIFIER, 212 --OID signalling TSTReqData 213 content DCSReqData } 214 certificate [0] Certificate, 215 signerInfos SignerInfos } } 217 The data certification request MUST either be unsigned or contain only 218 the signature of the requester. 220 DCSReqData ::= SEQUENCE { 221 dcsReqInfo DCSReqInfo, 222 data Data 224 --the data to be certified 225 --this field MUST be of type Message if the service type is cs 226 --and of type SEQUENCE OF Certificate if the service type is cpkc 227 } 229 The dcsReqInfo field contains information pertaining to the data 230 certification request. 232 DCSReqInfo ::= SEQUENCE { 233 version Integer { v1(0) }, 234 service ServiceType, 235 requester GeneralName OPTIONAL, 236 --MUST be present if the service field is cpd 237 --MUST match the identity (subjectName or subjectAltName 238 --extension) for the corresponding signing certificate 239 reqPolicy PolicyInformation OPTIONAL, 240 dcs GeneralName, 241 nonce Integer, 242 reqTime ReqTime OPTIONAL, 243 extensions Extensions OPTIONAL } 245 ReqTime ::= CHOICE { 246 genTime GeneralizedTime, 247 timeStampToken TimeStampToken } 249 In situations where the Data Certification Server will verify the 250 identity of the requester (i.e., when the service field is cpd), the 251 data certification request MUST be signed by the requester using the 252 signerInfos field. 254 Similarly, in situations where the Data Certification Server will 255 certify the time included in the request (i.e., when stipulated by the 256 policy of the Data Certification Server), the data certification 257 request MUST include the reqTime field in DCSReqInfo. Thus, when 258 verifying a public key certificate, the presence of this field indicates 259 the time for which the validity and revocation status of the certificate 260 SHOULD be reported. If this field is not present, the current time is 261 assumed. TimeStampToken is defined in Sect 2.4 of [TSA]. 263 PolicyInformation is defined in Section 4.2.1.5 of [CCP]. The 264 reqPolicy field SHOULD indicate the policy under which the certification 265 is requested. This field MUST be checked by the DCS to verify agreement 266 with its own policy. The absence of this field indicates that any 267 policy is acceptable. 269 The Data type is defined to be either the message itself, a hash of 270 the message (this allows a signature indicating possession of private 271 data to be certified) or the certificate to be verified. 273 Data ::= CHOICE { 274 message [0] Message, 275 messageimprint [1] MessageImprint, 276 certs [2] SEQUENCE SIZE (1..MAX) OF 277 TargetandChain } 279 In order to specify the format (i.e. the type) of the message so that 280 it may be parsed and understood by the DCS or any verifying entity, we 281 define the Message data type. 283 Message ::= SEQUENCE { 284 format MESSAGECLASS.&id, --objid 285 rawdata MESSAGECLASS.&Type --open type 286 } 288 MESSAGECLASS ::= CLASS { 289 &id OBJECT IDENTIFIER UNIQUE, 290 &Type } 291 WITH SYNTAX { &Type IDENTIFIED BY &id } 293 Possible message types include id-data and id-signedData [CMS]. 295 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) 296 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } 298 id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) 299 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } 301 In particular, if the message type is id-signedData (or any other 302 message type that allows more than one signature) and more than one 303 SignerInfo (or signature) is present under service type cs, the DCS 304 MUST verify all signatures present. In this case the failure of any 305 one signature to verify will result in the failure of the entire 306 certification. 308 If the requester prefers to send a hash of the message instead, the 309 MessageImprint data type SHOULD be used. 311 MessageImprint ::= SEQUENCE { 312 hashAlgorithm AlgorithmIdentifier, 313 hashedMessage OCTET STRING } 315 The hash algorithm indicated in the hashAlgorithm field SHOULD be a 316 "strong" hash algorithm (that is, it SHOULD be one-way and collision 317 resistant). It is up to the Data Certification Server to decide whether 318 or not the given hash algorithm is sufficiently "strong" (based on the 319 current state of knowledge in cryptanalysis and the current state of the 320 art in computational resources, for example). 322 The hashedMessage field SHOULD contain the hash of the DER encoding of 323 the message expressed as a Message data type. The hash is represented 324 as an OCTET STRING. 326 TargetandChain ::= SEQUENCE { 327 target Certificate, 328 chain SEQUENCE SIZE (1..MAX) OF Certificate 329 OPTIONAL, 330 pathProcInput PathProcInput OPTIONAL } 332 PathProcInput ::= SEQUENCE { 333 acceptablePolicySet CertificatePolicies, 334 inhibitPolicyMapping BOOLEAN DEFAULT FALSE, 336 explicitPolicyReqd BOOLEAN DEFAULT FALSE } 338 The certs field SHOULD contain the certificate to be certified. Each 339 certificate SHALL be included in a separate instance of TargetandChain. 340 The target field SHALL contain the cert to be verified and the chain 341 field, if present, MUST indicate the chain of trust to be used when 342 certifying the certificate. The pathProcInput field, if present, SHOULD 343 indicate the acceptable policy set and initial settings for 344 explicit-policy-indicator and inhibit-policy-mapping indicators to be 345 used in X.509 public key certificate path validation (see [CCP]). 346 CertificatePolicies is defined in Section 4.2.1.5 of [CCP]. 348 Extensions are described in Section 4.2 of [CCP]. The criticality of 349 the extensions MUST be honoured by conformant DCSs and clients (e.g. 350 requests and responses containing critical extensions which are not 351 understood MUST be rejected). 353 A data certification token is as follows. It is encapsulated as a 354 SignedData construct [CMS]. The content is of type DCSReqData. 356 DCSToken ContentInfo ::= SEQUENCE { 357 contentType OBJECT IDENTIFIER, 358 --{pkcs-7 2}, SignedData 359 content [0] SEQUENCE { 360 version INTEGER, 361 digestAlgorithms AlgorithmIdentifier, 362 contentInfo SEQUENCE { 363 contentType OBJECT IDENTIFIER, 364 --OID signalling DCSInfo 365 content DCSInfo } 366 certificate [0] Certificate, 367 signerInfos SignerInfos } } 369 The data certification token MUST contain only the signature of the DCS. 371 DCSInfo ::= SEQUENCE { 372 dcsReqInfo DCSReqInfo, 373 --MUST be the same value as the dcsReqInfo field in DCSReqData 374 messageImprint MessageImprint, 375 --if the data field in DCSReqData is MessageImprint, this 376 --MUST contain that same value, otherwise it contains a hash of 377 --the data field in DCSReqData using the hash algorithm 378 --specified in the digestAlgorithm parameter of SignerInfo in 379 --the data certification token 380 reqSignature SignerInfo OPTIONAL, 381 --MUST be present if service field of dcsReqInfo is cpd 382 --MUST be the same value as the signerInfo field in the data 383 --certification request 384 policy PolicyInformation, 385 status PKIStatusInfo, 386 time DCSTime, 387 serialNumber Integer OPTIONAL, 388 chainCerts [0] SEQUENCE OF Certificate OPTIONAL, 389 --if present, MUST indicate the chain of trust that was used by 390 --the DCS to verify the signature or certificate in DCSReqData 391 crls [2] SEQUENCE OF CertificateList OPTIONAL, 393 policyReturnInfo [3] SEQUENCE OF PolicyReturnInfo OPTIONAL, 394 extensions Extensions OPTIONAL } 396 DCSTime ::= CHOICE { 397 genTime GeneralizedTime, 398 timeStampToken TimeStampToken } 400 PolicyReturnInfo ::= SEQUENCE { 401 policies SEQUENCE OF PolicyInformation, 402 mappings SEQUENCE OF PolicyMappingsSyntax } 404 PKIStatusInfo is defined in Section 3.2.3 of [CMP]. If the PKIStatus 405 field has value `waiting' (3), then this token is a receipt, as defined 406 in Section 2. Otherwise, the status field indicates whether or not the 407 data certification request was fulfilled and, if not, failInfo indicates 408 the reason it was rejected. A valid data certification token will have 409 a PKIStatus field with value `granted' (0). For the purposes of the 410 DCS, we define PKIFailureInfo for use in PKIStatusInfo. 412 PKIFailureInfo ::= BITSTRING { 413 badAlg (0), 414 -- unrecognized or unsupported Algorithm Identifier 415 badMessageCheck (1), 416 -- integrity check failed (e.g., signature did not verify) 417 badRequest (2), 418 -- transaction not permitted or supported 419 badTime (3), 420 -- messageTime was not sufficiently close to the system time, 421 -- as defined by local policy 422 badCertId (4), 423 -- no certificate could be found matching the provided criteria 424 badDataFormat (5), 425 -- the data submitted has the wrong format 426 wrong (6), 427 -- the indicated in the request is different from the 428 -- one creating the response token 429 incorrectData (7), 430 --the requester's data (i.e. signature) is incorrect 431 --(i.e. invalid) 432 missingTimeStamp (8), 433 -- when the timestamp is missing but should be there (by policy) 434 certInvalid (9), 435 -- the certificate fails to validate against Section 6 of [CCP] 436 certRevoked (10), 437 -- the certificate is revoked 438 certExpired (11), 439 -- the certificate has expired 440 certOnHold (12), 441 -- the certificate has been operationally suspended 442 certNotActive (13) 443 -- the certificate was not active at the given time 444 } 446 The statusString field of PKIStatusInfo can be used to include reason 447 text such as "CA's public key revoked". 449 CertId is defined in Section 7.5 of [CRMF]. 451 The crls field (if present) SHOULD contain a sequence of certificate 452 revocation lists that is sufficient to verify the chain of trust 453 indicated in the chainCerts field. 455 The policyReturnInfo field indicates the policies and mappings that 456 were processed during X.509 public key certificate path validation. 457 PolicyMappingsSyntax is defined in [CCP]. 459 The reqSignature, chainCerts, crls and policyReturnInfo fields are 460 included as OPTIONAL. They SHOULD be present, when policy dictates, for 461 use as supplementary evidence when resolving possible disputes. Dispute 462 resolution would most likely be handled by one or more humans, in an 463 off-line environment, and is beyond the scope of this document. 465 6. Transports 467 There is no mandatory transport mechanism in this document. All 468 mechanisms are optional. 470 6.1. File Based Data Certification Server Protocol 472 A file containing a data certification message MUST contain only the DER 473 encoding of one PKI message, i.e. there MUST be no extraneous header or 474 trailer information in the file. 476 Such files can be used to transport data certification messages using 477 for example, FTP. 479 6.2. Socket Based Data Certification Server Protocol 481 The socket based protocol for data certification messages is identical 482 to that used in [CMP] Section 5.2 except that port 309 MUST be used. 484 6.3. Data Certification Server Protocol Using Email 486 This section specifies a means for conveying ASN.1-encoded messages 487 for the protocol exchanges described in Section 4 via Internet mail. 489 A simple MIME object is specified as follows. 491 Content-Type: application/dcs 492 Content-Transfer-Encoding: base64 494 <> 497 This MIME object can be sent and received using MIME processing engines 498 and provides a simple Internet mail transport for Data Certification 499 Server messages. 501 6.4. Data Certification Server Protocol via HTTP 503 This subsection specifies a means for conveying ASN.1-encoded messages 504 for the protocol exchanges described in Section 4 via the HyperText 506 Transfer Protocol. 508 A simple MIME object is specified as follows. 510 Content-Type: application/dcs 512 <> 514 This MIME object can be sent and received using common HTTP processing 515 engines over WWW links and provides a simple browser-server transport 516 for Data Certification Server messages. 518 7. Security Considerations 520 This entire document discusses security considerations. 522 When designing a data certification service, the following 523 considerations have been identified that have an impact upon the 524 validity or "trust" in the data certification token. 526 1. The enclosed public key certificate is revoked or the signer's 527 key is compromised and the corresponding public key certificate 528 is revoked before the Data Certification Server acts upon the 529 request. The Data Certification Server is REQUIRED to validate 530 appropriate information within the request before it 531 constructs the data certification token. It is therefore 532 mandated that the DCS have access to current information 533 regarding public key certificate status before it creates the 534 token. In this situation, the certification process would 535 produce an error. 536 2. The enclosed public key certificate is revoked or the signer's 537 key is compromised and the corresponding certificate is revoked 538 after the Data Certification Server acts upon the request. This 539 is not a concern to the DCS once the Data Certification Server 540 has constructed the token, as long as the compromise date in the 541 CRL is not before the time of certification. If it is, this 542 situation would have to be handled by off-line, possibly human- 543 aided, means specific to the situation at hand. 544 3. The Data Certification Server's private key is compromised and 545 the corresponding certificate is revoked. In this case, any 546 token signed by the Data Certification Server cannot be trusted. 547 For this reason, it is imperative that the Data Certification 548 Server's key be guarded with proper security and controls in 549 order to minimize the possibility of compromise. Nevertheless, 550 in case the private key does become compromised, an audit trail 551 of all the tokens generated by the DCS SHOULD be kept as a means 552 to help discriminate between genuine and false tokens. 553 4. The DCS signing key MUST be of a sufficient length to allow for 554 a sufficiently long lifetime. Even if this is done, the key 555 will have a finite lifetime. Thus, any token signed by the DCS 556 SHOULD be time stamped (if authentic copies of old CRLs 557 are available) or certified again (if they aren't) at a later 558 date to renew the trust that exists in the DCS's signature. 559 Data certification tokens could also be kept with an Evidence 560 Recording Authority [ISONR] to maintain this trust. 561 5. When there is a reason to believe that the DCS can no longer 563 be trusted, its certificate MUST be revoked and placed on the 564 appropriate CRL. Thus, at any future time the tokens signed 565 with the corresponding key will not be trusted. 566 6. In certain circumstances, a DCS may not be able to produce a 567 valid response to a request (for example, if it is unable to 568 compute signatures for a period of time). In these situations 569 the DCS MUST wait until it is again able to produce a valid 570 response and then respond to the request. Under no 571 circumstances shall a DCS produce an unsigned response to a 572 request. 573 7. A CA shall normally conduct a test for proof of possession for 574 each user's signing private key (including the DCS signing 575 private key). However, in some environments, the CA might not 576 perform a proof-of-possession of the private key when issuing 577 certificates. In these instances, in order to prevent certain 578 attacks and to properly check the validity of the binding 579 between an end entity and a key pair, a certificate identifier 580 of the DCS (resp. user) shall be included as a signed attribute 581 of the token (resp. request). 583 8. Patent Information 585 The following United States Patents related to data certification 586 servers (notaries), listed in chronological order, are known by the 587 authors to exist at this time. This may not be an exhaustive list. 588 Other patents may exist or be issued at any time. Implementers of this 589 protocol SHOULD perform their own patent search and determine whether or 590 not any encumberences exist on their implementation. 592 # 4,309,569 Method of Providing Digital Signatures 593 (issued) January 5, 1982 594 (inventor) Ralph C. Merkle 595 (assignee) The Board of Trustees of the Leland Stanford Junior 596 University 598 # 5,001,752 Public/Key Date-Time Notary Facility 599 (issued) March 19, 1991 600 (inventor) Addison M. Fischer 602 # 5,022,080 Electronic Notary 603 (issued) June 4, 1991 604 (inventors) Robert T. Durst, Kevin D. Hunter 606 # 5,136,643 Public/Key Date-Time Notary Facility 607 (issued) August 4, 1992 608 (inventor) Addison M. Fischer 609 (Note: This is a continuation of patent # 5,001,752.) 611 # 5,136,646 Digital Document Time-Stamping with Catenate Certificate 612 (issued) August 4, 1992 613 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 614 (assignee) Bell Communications Research, Inc., 616 # 5,136,647 Method for Secure Time-Stamping of Digital Documents 617 (issued) August 4, 1992 618 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 619 (assignee) Bell Communications Research, Inc., 621 # 5,373,561 Method of Extending the Validity of a Cryptographic 622 Certificate 623 (issued) December 13, 1994 624 (inventors) Stuart A. Haber, Wakefield S. Stornetta Jr. 625 (assignee) Bell Communications Research, Inc., 627 # 5,422,95 Personal Date/Time Notary Device 628 (issued) June 6, 1995 629 (inventor) Addison M. Fischer 631 9. References 633 [TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Internet X.509 634 Public Key Infrastructure, Time Stamp Protocols," draft-ietf-pkix-time- 635 stamp-0X.txt, 1998 (work in progress). 637 [CMP] C. Adams, S. Farrell, "Internet X.509 Public Key Infrastructure, 638 Certificate Management Protocols," draft-ietf-pkix-ipki3cmp- 639 0X.txt, 1998 (work in progress). 641 [CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key 642 Infrastructure, Certificate and CRL Profile," draft-ietf-pkix-ipki- 643 part1-0X.txt, 1998 (work in progress). 645 [CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms- 646 0X.txt, 1998 (work in progress). 648 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 649 Non-Repudiation Framework. 651 [RFC2119] Key works for use in RFCs to Indicate Requirement Levels, 652 S. Bradner, RFC 2119, March 1997. 654 [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp "Internet X.509 Certificate 655 Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 (work in 656 progress). 658 10. Authors' Addresses 660 Carlisle Adams Robert Zuccherato 661 Entrust Technologies Entrust Technologies 662 750 Heron Road 750 Heron Road 663 Ottawa, Ontario Ottawa, Ontario 664 K1V 1A7 K1V 1A7 665 CANADA CANADA 666 cadams@entrust.com robert.zuccherato@entrust.com 668 APPENDIX A - Storage of Data and Token 670 A data certification token is useless without the data to which it 671 applies. For this reason tokens and their related data MUST be securely 672 stored together. The change of a single bit in either the data or the 673 token renders the entire certification process for that data 674 meaningless. Storage of tokens and data in a secure (e.g., tamper 675 proof) environment is strongly RECOMMENDED. 677 When data and data certification tokens are stored together, the 678 following ASN.1 data type MAY be used. 680 DataAndToken ::= SEQUENCE { 681 message Message, 682 dcsToken DCSInfo } 684 Note that this object does not need to be signed, as the data 685 certification token already verifies the integrity of the data in the 686 message. Any supplementary information whose integrity needs to be 687 protected SHOULD be part of the message or token. 689 APPENDIX B - Extending the Life of a Signature 691 We present an example of a possible use of this data certification 692 service. It produces a stand-alone token that can be used to extend the 693 life of a signature. This example assumes that we have total trust in 694 the Data Certification Server. 696 Signature algorithms and keys have a definite lifetime. Therefore, 697 signatures have a definite lifetime. The Data Certification Server can 698 be used to extend the lifetime of a signature. 700 In order to extend the lifetime of a signature in this way, the 701 following technique MAY be used. 703 A) The signature needs to be certified. 705 1) The signed message is presented to the Data Certification Server 706 in the data field of DCSReqInfo under service type cs and an 707 appropriate policy. 709 2) The Data Certification Server verifies that the signature and 710 verification key are valid at that time by checking expiry dates 711 and status information, and returns a data certification token. 713 B) The certified signature MUST be verified. 715 1) The signature of the Data Certification Server in data 716 certification token SHALL be verified using the Data 717 Certification Server's valid verification key. 719 In this situation the signer's signing key (and therefore, its 720 signature) is only valid until some specified time T1. The DCS's 721 signing key (and therefore, its signature) is valid until some specified 723 time T2 that is (usually) after time T1. Without certification, the 724 signer's signature would only be valid until time T1. With 725 certification, the signer's signature remains valid until time T2, 726 regardless of subsequent revocation or expiry at time T1. 728 If the signature of the DCS is valid, the trust we have in the DCS 729 allows us to conclude that the original signature on the data was valid 730 at the time included in the dcsInfo field of the data certification 731 token. 733 APPENDIX C - Verifying the Status of a Public Key Certificate 735 We now present an example of how to produce a stand-alone token that can 736 be used to confirm the revocation status of a public key certificate. 738 CRLs and ARLs are updated according to a schedule at regular intervals. 739 For some purposes, the granularity provided by the CRLs and ARLs is not 740 fine enough. Up-to-date revocation status may be needed before the next 741 CRL or ARL update. Since the DCS MUST have access to current 742 information regarding public key certificate status, it can also be used 743 to verify the revocation status of a certificate in this situation. 745 In order to produce such a token, the following technique MAY be used. 747 A) The public key certificate needs to be certified. 749 1) The certificate is presented to the Data Certification Server in 750 the data field of DCSReqInfo under service type cpkc and an 751 appropriate policy. 753 2) The Data Certification Server verifies that the public key 754 certificate is valid and that it hasn't been revoked and then 755 returns a data certification token. 757 B) The data certification token MUST be verified. 759 1) The signature of the Data Certification Server in the data 760 certification token SHALL be verified using the Data 761 Certification Server's valid verification key. 763 This data certification token can now be used when verifying signatures 764 using the key contained in the public key certificate. This service 765 provided by the DCS can be thought of as a supplement to the usual 766 method of checking revocation status.