idnits 2.17.1 draft-adams-notary-01.txt: -(50): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(53): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(169): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(325): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(506): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-16) 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. == There are 36 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 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 12 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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: ---------------------------------------------------------------------------- -- 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 (February 27, 1997) is 9910 days in the past. Is this intentional? 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 314 -- Looks like a reference, but probably isn't: '1' on line 249 -- Looks like a reference, but probably isn't: '2' on line 317 -- 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 (~~), 5 warnings (==), 14 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 February 27, 1997 5 Notary 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 notary service and the protocols to 30 be used when communicating with it. The Notary Authority is a Trusted 31 Third Party (TTP) that can be used as one component in building reliable 32 non-repudiation services (see [ISONR]). Useful Notary Authority 33 responsibilities in a PKI are to validate signatures and to provide up- 34 to-date information regarding the status of certificates. We give 35 examples of how to use the notary to extend the lifetime of a signature 36 beyond key expiry or revocation and to query the notary regarding the 37 status of a certificate. 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 40 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 41 "OPTIONAL" in this document are to be interpreted as described in 42 RFC 2119 [RFC2119]. 44 1. Introduction 46 A Notary Authority (NA) is a Trusted Third Party that verifies the 47 correctness of specific data submitted to it. The Notary Authority 48 provides the notary service in order that non-repudiation evidence may 49 be constructed relating to the validity and correctness of an entity's 50 claim to possess data, the validity and revocation status of an entity�s 51 public key certificate and/or the validity and correctness of another 52 entity�s signature. When notarizing possession of data or another 53 entity�s signature, the NA verifies the mathematical correctness of the 54 actual signature value contained in the request and also checks the full 56 certification path from the signing entity to a trusted point (e.g., the 57 NA's CA, or the root CA in a hierarchy). The NA MAY be able to rely on 58 all relevant CRLs and ARLs, or the NA MAY need to supplement this with 59 access to more current status information from the CA. It then includes 61 a trusted time and creates a notary token. (See Appendix B.) 63 When notarizing a certificate, the NA verifies that the certificate 64 included in the request is a valid certificate and determines its 65 revocation status at a specified time. Again, it checks the full 66 certification path from the certificate signing entity to a trusted 67 point. The NA MAY be able to rely on all relevant CRLs and ARLs, or the 68 NA MAY need to supplement this with access to more current status 69 information from the CA. It includes this information, along with a 70 trusted time, to create a Notary Token. (See Appendix C.) 72 The presence of a notary token supports non-repudiation in two ways. 73 It provides evidence that a signature or certificate was valid at the 74 time of notarization. This token can be used even after the 75 corresponding certificate expires and its revocation information is 76 no longer available on CRLs (for example). The production of a notary 77 token in response to a signed request for notarization of another 78 signature or certificate also provides evidence that due diligence 79 was performed by the requester in validating the signature or 80 certificate. 82 In all cases, the trust that PKI entities have in the Notary Authority 83 is transferred to the contents of the notary token (just as trust in a 84 CA is transferred to the certificates that it issues). As a particular 85 example, a notary token pertaining to a signature may be useful for 86 extending the life of that signature beyond the expiry or subsequent 87 revocation of its corresponding verification certificate. 89 2. Requirements of the Notary Authority 91 The Notary Authority is MAY to: 93 1. verify the correctness of the enclosed digital signature using 94 all appropriate status information and public key certificates 95 and produce a signed notary token attesting to the validity of 96 the signature, if asked by the requester. 97 2. verify the validity (according to [CCP]) of the enclosed 98 certificate and its revocation status at the specified time 99 using all appropriate status information and public key 100 certificates and produce a signed notary token attesting to the 101 validity and revocation status of the certificate, if asked by 102 the requester. 103 3. include a monotonically incrementing value of the time of day 104 or a time stamp token into its notary token. 105 4. include within each signed notary token an identifier to 106 uniquely determine the trust and validation policy used for this 107 signature. 108 5. sign each notary token using a key generated exclusively for 109 this purpose and have this property of the key indicated on the 110 corresponding certificate. 112 6. indicate in the token whether or not the signature or 113 certificate verified, and if not, the reason the verification 114 failed. 115 7. provide a signed receipt (i.e., in the form of an appropriately 116 defined notary token) to the requester, where appropriate, as 117 defined by policy. 119 3. Notary Transactions 121 As the first transaction of this mechanism, the requesting entity 122 requests a notarization by sending a request (which is or includes a 123 notary request, as defined below), including the data for which validity 124 and/or possession is to be notarized, to the Notary Authority. Upon 125 receiving the request, the Notary Authority reviews and checks the 126 validity of the request. A valid request is of the form described in 127 Section 5 of this document and can be properly decoded. If the request 128 is valid, the Notary Authority performs the notarization and sends a 129 response (which is or includes a notary token, as defined below) to the 130 requesting entity. Otherwise, the Notary Authority returns an error 131 message (i.e., in the form of an appropriately defined notary token). 133 Upon receiving the token, the requesting entity verifies its validity. 134 The requester SHOULD verify that it contains the correct time, the 135 correct name for the NA, the correct data imprint, a valid signature, 136 and satisfactory status, service and policy fields. Since the NA�s 137 certificate may have been revoked, the appropriate status information 138 SHOULD be checked to verify that the certificate is still valid. The 139 token can now be used to authenticate the correctness or possession of 140 the corresponding data. 142 4. Identification of the NA 144 The NA MUST sign all notary messages with a key reserved specifically 145 for that purpose. The corresponding certificate MUST contain the 146 extended key usage field extension as defined in [CCP] Section 147 4.2.1.14 with KeyPurposeID having value id-kp-notary. This extension 148 MUST be critical. 150 id-kp-notary OBJECT IDENTIFIER ::= {id-kp ??} 151 -- Notarizing the validity of certain information. Key usage bits 152 -- that may be consistent: digitalSignature, nonRepudiation 154 5. Request and Token Formats 156 The ServiceType type indicates which type of Notary Service is required. 158 ServiceType ::= INTEGER { npd(1), ns(2), nc(3) } 160 The value npd (Notarize Possession of Data) is used when only the 161 signature on the notary request (i.e., possession of the data in the 162 request) is to be verified. In this case the Notary Authority would be 163 merely providing evidence that the requester possessed the data in the 164 request and a valid signature key at the time indicated. This is really 165 an extension of the Time Stamp Authority [TSA] in that we are given the 166 additional assurance about the validity of the signature, as well as the 167 time before which it was applied. The value ns (Notarize Signature) is 169 used when another entity�s signature is to be validated. The resulting 170 token can then be used to support non-repudiation services or to allow 171 use of the signature beyond certificate revocation or expiry. 173 The value nc (Notarize Certificate) is used when the validity and 174 revocation status of the certificate included in the request is to be 175 verified. This service can be used to supplement the use of CRLs when 176 timely information regarding a certificate�s revocation state is 177 required (e.g. high value funds transfer or the compromise of a highly 178 sensitive key) or when evidence supporting non-repudiation is required. 179 A given NA MAY support any subset of the above services. 181 Upon receiving a signed request for either service ns or nc the NA MUST 182 also verify the signature on the request as is done for the npd service. 183 Note however, that signed requests for the ns or nc service are not 184 required. 186 A notary request is as follows. It is encapsulated as a SignedData 187 construct [CMS]. The content is of type NotaryReqData, which is 188 indicated by the OID: 190 NotaryReqData OBJECT IDENTIFIER ::= { ?????? } 192 The notary request MUST contain only the signature of the requester. 194 The data and information that will be notarized are contained in the 195 content field of the SignedData content type. 197 NotaryReqData ::= SEQUENCE { 198 notaryReqInfo NotaryReqInfo, 199 data Data 200 --the data to be notarized 201 --this field MUST be of type Message if the service type is ns 202 --and of type SEQUENCE OF Certificate if the service type is nc 203 } 205 The notaryReqInfo field contains information pertaining to the notary 206 request. 208 NotaryReqInfo ::= SEQUENCE { 209 version Integer { v1(0) }, 210 service ServiceType, 211 requester GeneralName OPTIONAL, 212 --MUST be present if the service field is npd 213 --MUST match the identity (subjectName or subjectAltName 214 --extension) for the corresponding signing certificate 215 reqPolicy PolicyInformation OPTIONAL, 216 notary GeneralName, 217 nonce Integer, 218 reqTime ReqTime OPTIONAL } 220 ReqTime ::= CHOICE { 221 genTime GeneralizedTime, 222 timeStampToken TimeStampToken } 224 In situations where the Notary Authority will verify the identity of the 225 requester (i.e., when the service field is npd), the notary request MUST 226 be signed by the requester using the signerInfos field. 228 Similarly, in situations where the Notary Authority will certify the 229 time included in the request (i.e., when stipulated by the policy of the 230 Notary Authority), the notary request MUST include the reqTime field in 231 NotaryReqInfo. Thus, when verifying a certificate, the presence of this 232 field indicates the time for which the validity and revocation status of 233 the certificate SHOULD be reported. If this field is not present, the 234 current time is assumed. TimeStampToken is defined in Sect 2.4 of [TSA]. 236 PolicyInformation is defined in Section 4.2.1.5 of [CCP]. The 237 reqPolicy field SHOULD indicate the policy under which the notarization 238 is requested or the policy for which certificate validity is to be 239 reported. This field MUST be checked by the NA to verify agreement 240 with its own policy or to determine certificate validity. The absence 241 of this field indicates that any policy is acceptable. 243 The Data type is defined to be either the message itself, a hash of 244 the message (this allows a signature indicating possession of private 245 data to be notarized) or the certificate to be verified. 247 Data ::= CHOICE { 248 message [0] Message, 249 messageimprint [1] MessageImprint, 250 cert [2] SEQUENCE SIZE (1..MAX) OF Certificate 251 } 253 In order to specify the format (i.e. the type) of the message so that 254 it may be parsed and understood by the NA or any verifying entity, we 255 define the Message data type. 257 Message ::= SEQUENCE { 258 format MESSAGECLASS.&id, --objid 259 rawdata MESSAGECLASS.&Type --open type 260 } 262 MESSAGECLASS ::= CLASS { 263 &id OBJECT IDENTIFIER UNIQUE, 264 &Type } 265 WITH SYNTAX { &Type IDENTIFIED BY &id } 267 If the requester prefers to send a hash of the message instead, the 268 MessageImprint data type SHOULD be used. 270 MessageImprint ::= SEQUENCE { 271 hashAlgorithm AlgorithmIdentifier, 272 hashedMessage OCTET STRING } 274 The hash algorithm indicated in the hashAlgorithm field SHOULD be a 275 �strong� hash algorithm (that is, it SHOULD be one-way and collision 276 resistant). It is up to the Notary Authority to decide whether or not 277 the given hash algorithm is sufficiently �strong� (based on the current 278 state of knowledge in cryptanalysis and the current state of the art in 279 computational resources, for example). 281 The hashedMessage field SHOULD contain the hash of the DER encoding of 282 the message expressed as a Message data type. The hash is represented 283 as an OCTET STRING. 285 The cert field SHOULD contain the certificate to be notarized. If the 286 sequence has length greater than 1, then the certificates MUST indicate 287 a chain of trust to be used when notarizing the certificate. 289 A notary token is as follows. It is encapsulated as a SignedData 290 construct [CMS]. The content is of type NotaryInfo, which is indicated 291 by the OID: 293 NotaryInfo OBJECT IDENTIFIER ::= { ?????? } 295 The notary token MUST contain only the signature of the NA. 297 NotaryInfo ::= SEQUENCE { 298 notaryReqInfo NotaryReqInfo, 299 --MUST be the same value as the notaryReqInfo field in 300 --NotaryReqData 301 messageImprint MessageImprint, 302 --if the data field in NotaryReqData is MessageImprint, this 303 --MUST contain that same value, otherwise it contains a hash of 304 --the data field in NotaryReqData using the hash algorithm 305 --specified in the digestAlgorithm parameter of SignerInfo in 306 --the notary token 307 reqSignature SignerInfo OPTIONAL, 308 --MUST be present if service field of notaryReqInfo is npd 309 --MUST be the same value as the signerInfo field in notary 310 request 311 policy PolicyInformation, 312 status PKIStatusInfo, 313 time NotaryTime, 314 chainCerts [0] SEQUENCE OF Certificate OPTIONAL, 315 --if present, MUST indicate the chain of trust that was used by 316 --the NA to verify the signature or certificate in NotaryReqData 317 crls [2] SEQUENCE OF CertificateList OPTIONAL 318 } 320 NotaryTime ::= CHOICE { 321 genTime GeneralizedTime, 322 timeStampToken TimeStampToken } 324 PKIStatusInfo is defined in Section 3.2.3 of [CMP]. If the PKIStatus 325 field has value �waiting� (3), then this token is a receipt, as defined 326 in Section 2. Otherwise, the status field indicates whether or not the 327 notary request was fulfilled and, if not, failInfo indicates the reason 328 it was rejected. A valid notary token will have a PKIStatus field with 329 value �granted� (0). For the purposes of the NA, we define 330 PKIFailureInfo for use in PKIStatusInfo. 332 PKIFailureInfo ::= BITSTRING { 333 badAlg (0), 334 -- unrecognized or unsupported Algorithm Identifier 335 badMessageCheck (1), 336 -- integrity check failed (e.g., signature did not verify) 338 badRequest (2), 339 -- transaction not permitted or supported 340 badTime (3), 341 -- messageTime was not sufficiently close to the system time, 342 -- as defined by local policy 343 badCertId (4), 344 -- no certificate could be found matching the provided criteria 345 badDataFormat (5), 346 -- the data submitted has the wrong format 347 wrongAuthority (6), 348 -- the authority indicated in the request is different from the 349 -- one creating the response token 350 incorrectData (7), 351 --the requester's data (i.e. signature) is incorrect 352 --(i.e. invalid) 353 missingTimeStamp (8), 354 -- when the timestamp is missing but should be there (by policy) 355 certInvalid (9), 356 -- the certificate fails to validate against Section 6 of [CCP] 357 certRevoked (10), 358 -- the certificate is revoked 359 certExpired (11), 360 -- the certificate has expired 361 certOnHold (12), 362 -- the certificate has been operationally suspended 363 certNotActive (13) 364 -- the certificate was not active at the given time 365 } 367 The statusString field of PKIStatusInfo can be used to include reason 368 text such as �CA�s public key revoked�. 370 CertId is defined in Section 7.5 of [CRMF]. 372 The crls field (if present) SHOULD contain a sequence of certificate and 373 authority revocation lists that is sufficient to verify the chain of 374 trust indicated in the chainCerts field. 376 The reqSignature, chainCerts and crls fields are included as OPTIONAL. 377 They SHOULD be present, when policy dictates, for use as supplementary 378 evidence when resolving possible disputes. Dispute resolution would 379 most likely be handled by one or more humans, in an off-line 380 environment, and is beyond the scope of this document. 382 6. Transports 384 6.1. File Based Notary Protocol 386 A file containing a notary message MUST contain only the DER encoding of 387 one PKI message, i.e. there MUST be no extraneous header or trailer 388 information in the file. 390 Such files can be used to transport notary messages using for example, 391 FTP. 393 6.2. Socket Based Notary Protocol 395 The socket based protocol for notary messages is identical to that used 396 in [CMP] Section 5.2 except that port 309 MUST be used. 398 6.3. Notary Protocol Using Email 400 This section specifies a means for conveying ASN.1-encoded messages 401 for the protocol exchanges described in Section 4 via Internet mail. 403 A simple MIME object is specified as follows. 405 Content-Type: application/notary 406 Content-Transfer-Encoding: base64 408 <> 410 This MIME object can be sent and received using MIME processing engines 411 and provides a simple Internet mail transport for Notary messages. 413 6.4. Notary Protocol via HTTP 415 This subsection specifies a means for conveying ASN.1-encoded messages 416 for the protocol exchanges described in Section 4 via the HyperText 417 Transfer Protocol. 419 A simple MIME object is specified as follows. 421 Content-Type: application/notary 423 <> 425 This MIME object can be sent and received using common HTTP processing 426 engines over WWW links and provides a simple browser-server transport 427 for Notary messages. 429 7. Security Considerations 431 This entire document discusses security considerations. 433 When designing a notary service, the following considerations have been 434 identified that have an impact upon the validity or �trust� in the 435 notary token. 437 1. The enclosed certificate is revoked or the signer�s key is 438 compromised and the corresponding certificate is revoked before 439 the notary acts upon the request. The notary is MAY to 440 validate appropriate information within the request before it 441 constructs the notary token. It is therefore mandated that the 442 NA have access to current information regarding certificate 443 status before it creates the token. In this situation, the 444 notarization process would produce an error. 445 2. The enclosed certificate is revoked or the signer�s key is 446 compromised and the corresponding certificate is revoked after 447 the notary acts upon the request. This is not a concern to the 448 NA once the notary has constructed the token, as long as the 450 compromise date in the CRL is not before the time of 451 notarization. If it is, this situation would have to be 452 handled by off-line, possibly human-aided, means specific to the 453 situation at hand. 454 3. The notary�s private key is compromised and the corresponding 455 certificate is revoked. In this case, any token signed by the 456 notary cannot be trusted. For this reason, it is imperative 457 that the notary�s key be guarded with proper security and 458 controls in order to minimize the possibility of compromise. 459 Nevertheless, in case the private key does become compromised, 460 an audit trail of all the tokens generated by the NA SHOULD be 461 kept as a means to help discriminate between genuine and false 462 tokens. 463 4. The NA signing key MUST be of a sufficient length to allow for 464 a sufficiently long lifetime. Even if this is done, the key 465 will have a finite lifetime. Thus, any token signed by the NA 466 SHOULD be time stamped (if authentic copies of old CRLs 467 are available) or notarized again (if they aren�t) at a later 468 date to renew the trust that exists in the NA�s signature. 469 Notary tokens could also be kept with an Evidence Recording 470 Authority [ISONR] to maintain this trust. 471 5. When there is a reason to believe that the NA can no longer 472 be trusted, the authority�s certificate MUST be revoked and 473 placed on the appropriate ARL. Thus, at any future time the 474 tokens signed with the corresponding key will not be trusted. 475 6. In certain circumstances, an NA may not be able to produce a 476 valid response to a request (for example, if it is unable to 477 compute signatures for a period of time). In these situations 478 the NA MUST wait until it is again able to produce a valid 479 response and then respond to the request. Under no 480 circumstances shall an NA produce an unsigned response to a 481 request. 482 7. This protocol assumes that the CA has conducted a test for proof 483 of possession for each user's signing private key. If this is 484 not the case, or when additional assurances are required, the 485 certificate of the reqester (resp. NA) SHALL be included in the 486 encapsulation of the notary request (resp. notary token) as an 487 authenticated attribute. 489 8. References 491 [TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, �Time Stamp 492 Protocols,� draft-adams-time-stamp-0X.txt, 1997 (work in progress). 494 [CMP] C. Adams, S. Farrell, �Internet Public Key Infrastructure, 495 Certificate Management Protocols,� draft-ietf-pkix-ipki3cmp- 496 0X.txt, 1997 (work in progress). 498 [CRMF] C. Adams, �Internet Public Key Infrastructure, Certificate 499 Request Message Format,� draft-ietf-pkix-crmf-0X.txt, 1998 (work in 500 progress). 502 [CCP] R. Housley, W. Ford, W. Polk, D. Solo, �Internet Public Key 503 Infrastructure, X.509 Certificate and CRL Profile,� draft- 504 ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress). 506 [CMS] R. Housley �Cryptographic Message Syntax�, draft-ietf-smime-cms- 507 02.txt, 1998 (work in progress). 509 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 510 Non-Repudiation Framework. 512 [RFC2119] Key works for use in RFCs to Indicate Requirement Levels, 513 S. Bradner, RFC 2119, March 1997. 515 9. Authors� Addresses 517 Carlisle Adams 518 Entrust Technologies 519 750 Heron Road 520 Ottawa, Ontario 521 K1V 1A7 522 CANADA 523 cadams@entrust.com 525 Robert Zuccherato 526 Entrust Technologies 527 750 Heron Road 528 Ottawa, Ontario 529 K1V 1A7 530 CANADA 531 robert.zuccherato@entrust.com 533 APPENDIX A - Storage of Data and Token 535 A notary token is useless without the data to which it applies. For 536 this reason tokens and their related data MUST be securely stored 537 together. The change of a single bit in either the data or the token 538 renders the entire notarization process for that data meaningless. 539 Storage of tokens and data in a secure (e.g., tamper proof) environment 540 is strongly RECOMMENDED. 542 When data and notary tokens are stored together, the following ASN.1 543 data type MAY be used. 545 DataAndToken ::= SEQUENCE { 546 message Message, 547 notaryToken Content Info } 549 Note that this object does not need to be signed, as the notary token 550 already verifies the integrity of the data in the message. Any 551 supplementary information whose integrity needs to be protected SHOULD 552 be part of the message or token. 554 APPENDIX B - Extending the Life of a Signature 556 We present an example of a possible use of this notary service. 557 It produces a stand-alone token that can be used to extend the life of a 558 signature. This example assumes that we have total trust in the Notary 559 Authority. 561 Signature algorithms and keys have a definite lifetime. Therefore, 562 signatures have a definite lifetime. The Notary Authority can be used 563 to extend the lifetime of a signature. 565 In order to extend the lifetime of a signature in this way, the 566 following technique MAY be used. 568 A) The signature needs to be notarized. 570 1) The signed message is presented to the Notary in the data 571 field of NotaryReqInfo under service type ns and an appropriate 572 policy. 574 2) The Notary verifies that the signature and verification key are 575 valid at that time by checking expiry dates and status 576 information, and returns a notary token. 578 B) The notarized signature MUST be verified. 580 1) The signature of the Notary in notary token SHALL be verified 581 using the Notary�s valid verification key. 583 In this situation the signer�s signing key (and therefore, its 584 signature) is only valid until some specified time T1. The NA�s 585 signing key (and therefore, its signature) is valid until some specified 586 time T2 that is (usually) after time T1. Without notarization, the 588 signer�s signature would only be valid until time T1. With 589 notarization, the signer�s signature remains valid until time T2, 590 regardless of subsequent revocation or expiry at time T1. 592 If the signature of the NA is valid, the trust we have in the NA allows 593 us to conclude that the original signature on the data was valid at 594 the time included in the notaryInfo field of the notary token. 596 APPENDIX C - Verifying the Status of a Certificate 598 We now present an example of how to produce a stand-alone token that can 599 be used to confirm the revocation status of a certificate. 601 CRLs and ARLs are updated according to a schedule at regular intervals. 602 For some purposes, the granularity provided by the CRLs and ARLs is not 603 fine enough. Up-to-date revocation status may be needed before the next 604 CRL or ARL update. Since the NA MUST have access to current information 605 regarding certificate status, it can be used to verify the revocation 606 status of a certificate in this situation. 608 In order to produce such a token, the following technique MAY be used. 610 A) The certificate needs to be notarized. 612 1) The certificate is presented to the Notary in the data field of 613 NotaryReqInfo under service type nc and an appropriate policy. 615 2) The Notary verifies that the certificate is valid and that it 616 hasn�t been revoked and then returns a notary token. 618 B) The notary token MUST be verified. 620 1) The signature of the Notary in notary token SHALL be verified 621 using the Notary�s valid verification key. 623 This notary token can now be used when verifying signatures using the 624 key corresponding to the certificate. This service provided by the 625 NA can be thought of as a supplement to the usual method of checking 626 revocation status.