idnits 2.17.1 draft-ietf-pkix-ipki6np-00.txt: -(344): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(434): 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-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. == There are 26 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 8 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 9 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 abstract seems to contain references ([ISONR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '... BIT STRING OPTIONAL...' RFC 2119 keyword, line 162: '... GeneralName OPTIONAL,...' RFC 2119 keyword, line 168: '... SEQUENCE OF Certificate OPTIONAL,...' RFC 2119 keyword, line 169: '... PolicyInformation OPTIONAL,...' RFC 2119 keyword, line 171: '... TimeStampToken OPTIONAL }...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. -- 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 (July 29, 1997) is 9768 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) -- Missing reference section? 'ISONR' on line 337 looks like a reference -- Missing reference section? 'PKIX5' on line 348 looks like a reference -- Missing reference section? 'PKIX1' on line 340 looks like a reference -- Missing reference section? 'PKIX3' on line 344 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group C. Adams(Entrust Technologies) 2 Internet Draft R. Zuccherato(Entrust Technologies) 3 expires in six months July 29, 1997 5 Internet Public Key Infrastructure 7 Part VI: Notary Protocols 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes a general notary service and the protocols to 32 be used when communicating with it. The Notary Authority is a Trusted 33 Third Party (TTP) that can be used as one component in building reliable 34 non-repudiation services (see [ISONR]). We also give an example of how 35 to use the notary to extend the lifetime of a signature beyond key 36 expiry or revocation. 38 1. Introduction 40 A Notary Authority (NA) is a Trusted Third Party that verifies 41 correctness of specific data submitted to it. The Notary Authority 42 provides the notary service in order that non-repudiation evidence may 43 be constructed relating to the validity and correctness of an entity's 44 claim to possess data and/or the validity and correctness of various 45 types of data at a particular instant in time. When notarizing 46 possession of data, the NA verifies the mathematical correctness of the 47 actual signature value contained in the request and also checks the full 48 certification path from the signing entity to a trusted point (e.g., the 49 NA's CA, or the root CA in a hierarchy) along with all relevant CRLs and 50 ARLs (Authority Revocation Lists). It then includes a trusted time and 51 creates a notary token. 53 When notarizing data, the NA verifies the correctness of the data and 54 creates a notary token. In this case, however, data "correctness" is 55 not as focused in scope as signature correctness; the particular 56 definition to be applied is therefore necessarily policy- and datatype- 57 dependent. For example, the data may itself contain one or more 58 signatures (where "correctness" relates to the validity of these 59 signatures), or it may contain assertions (where "correctness" relates 60 to the truth value of these statements), or it may contain a contract 61 (where "correctness" relates to the legal validity of the document). 63 In all cases, the trust that PKI entities have in the Notary Authority 64 is transferred to the contents of the notary token (just as trust in a 65 CA is transferred to the certificates that it issues). As a particular 66 example, a notary token pertaining to a signature may be useful for 67 extending the life of that signature beyond the expiry or subsequent 68 revocation of its corresponding verification certificate. 70 2. Requirements of the Notary Authority 72 The Notary Authority is required to: 74 1. verify the correctness of the enclosed digital signature using 75 all available and appropriate CRLs, ARLs, and public key 76 certificates and produce a signed notary token attesting to the 77 validity of the signature, if asked by the requester. 78 2. verify the correctness of the enclosed data with respect to 79 explicitly stated policies using all available and appropriate 80 resources and produce a signed notary token attesting to the 81 validity of the data, if asked by the requester. 82 3. include a monotonically incrementing value of the time of day 83 or a time stamp token into its notary token. 84 4. include within each signed notary token an identifier to 85 uniquely determine the trust and validation policy used for its 86 signature. 87 5. indicate in the token whether or not the signature or data 88 verified, and if not, the reason the verification failed. 89 6. provide a signed receipt (i.e. in the form of an appropriately 90 defined notary token) to the requester, where appropriate, as 91 defined by policy. 93 3. Notary Transactions 95 As the first transaction of this mechanism, the requesting entity 96 requests a notarization by sending a request (which is or includes a 97 TimeStampReq, as defined below) including the data for which validity 98 and/or possession is to be notarized to the Notary Authority. Upon 99 receiving the request, the Notary Authority reviews and checks the 100 validity of the request. If the request is valid, the Notary Authority 101 performs the notarization and sends a response (which is or includes a 102 TimeStampToken, as defined below) to the requesting entity. Otherwise, 103 the Notary Authority returns an error message (in the form of an 104 appropriately defined notary token). 106 Upon receiving the token, the requesting entity verifies its validity. 107 The requester should verify that it contains the correct time, the 108 correct name for the NA, the correct data imprint, a valid signature, 110 and satisfactory status, service and policy fields. The token can now 111 be used to authenticate the correctness or possession of the data. 113 4. Request and Token Formats 115 The ServiceType type indicates which type of Notary Service is required. 117 ServiceType ::= INTEGER { npd(1), nd(2), nb(3) } 119 The value npd (Notarize Possession of Data) is used when only the 120 signature on the NotaryReq (i.e., possession of the data in the request) 121 is to be verified. In this case the Notary Authority would be merely 122 providing evidence that the requester possessed the data in the request 123 and a valid signature key at the time indicated. This is really an 124 extension of the Time Stamp Authority in that we are given the 125 additional assurance about the validity of the signature, as well as the 126 time before which it was applied. The value nd (Notarize Data) is used 127 when only the data included in NotaryReqInfo is to be verified. This 128 verification may mean verifying a digital signature contained in the 129 data, verifying the correctness of the data, or verifying the intent of 130 parties to a contract contained in the data, for example. The exact 131 interpretation of this service must be clearly indicated in the NA�s 132 policy statement, but is implementation and policy dependent, and thus 133 beyond the scope of this document. The value nb (Notarize Both) is used 134 when both the signature and data are to be verified. A given NA may 135 support any subset of the above services. 137 A notary request is as follows. 139 NotaryReq ::= SEQUENCE { 140 notaryReqData NotaryReqData, 141 signature BIT STRING OPTIONAL 142 --over the ASN.1 DER encoding of NotaryReqInfo, must be present 143 --if the service field of NotaryReqInfo is npd or nb 144 } 146 The data and information that will be notarized is contained in the 147 notaryReqData field. 149 NotaryReqData ::= SEQUENCE { 150 notaryReqInfo NotaryReqInfo, 151 data Data 152 --the data to be notarized 153 --this field must be of type Message if the service type is nd 154 --or nb 155 } 157 The notaryReqInfo field contains information pertaining to the notary 158 request. 160 NotaryReqInfo ::= SEQUENCE { 161 service ServiceType, 162 requester GeneralName OPTIONAL, 163 --must be present if the service field is npd or nb 165 signatureAlgorithm AlgorithmIdentifier, 166 --must be present if the service field of NotaryReqInfo is 167 --npd or nb 168 certs SEQUENCE OF Certificate OPTIONAL, 169 reqPolicy PolicyInformation OPTIONAL, 170 notary GeneralName, 171 reqTime TimeStampToken OPTIONAL } 173 In situations where the Notary Authority will verify the identity of the 174 requester (i.e., when the service field is npd or nb), the notary 175 request must be signed by the requester using the signature field. 177 Similarly, in situations where the Notary Authority will certify the 178 time included in the request (i.e., when stipulated by the policy of the 179 Notary Authority), the notary request must include the reqTime field in 180 NotaryReqInfo. TimeStampToken is defined in Section 4 of PKIX Part 5 181 [PKIX5]. 183 PolicyInformation is defined in Section 4.2.1.5 of PKIX Part 1 [PKIX1]. 184 The reqPolicy field should indicate the policy under which the 185 notarization is requested. This field must be checked by the NA to 186 verify agreement with its own policy. 188 The Data type is defined to be either the message itself or a hash of 189 the message. This allows a signature indicating possession of private 190 data to be notarized. 192 Data ::= CHOICE { 193 message Message, 194 messageimprint MessageImprint } 196 In order to specify the format (i.e. the type) of the message so that 197 it may be parsed and understood by the NA or any verifying entity, we 198 define the Message data type. 200 Message ::= SEQUENCE { 201 format MESSAGECLASS.&id, --objid 202 rawdata MESSAGECLASS.&Type --open type 203 } 205 MESSAGECLASS ::= CLASS { 206 &id OBJECT IDENTIFIER UNIQUE, 207 &Type } 208 WITH SYNTAX { &Type IDENTIFIED BY &id } 210 If the requester prefers to send a hash of the message instead, the 211 MessageImprint data type should be used. 213 MessageImprint ::= SEQUENCE { 214 hashAlgorithm AlgorithmIdentifier, 215 hashedMessage OCTET STRING } 217 The hash algorithm indicated in the hashAlgorithm field should be a 218 �strong� hash algorithm (that is, it should be one-way and collision 219 resistant). It is up to the Notary Authority to decide whether or not 220 the given hash algorithm is sufficiently �strong�. 222 The hashedMessage field should contain the hash of the DER encoding of 223 the message expressed as a Message data type. The hash is represented 224 as an OCTET STRING. 226 A notary token is as follows. 228 NotaryToken ::= SEQUENCE { 229 notaryInfo NotaryInfo, 230 signature BIT STRING, 231 --over the ASN.1 DER encoding of NotaryInfo 232 } 234 NotaryInfo ::= SEQUENCE { 235 notaryReqInfo NotaryReqInfo, 236 --must be the same value as the notaryReqInfo field in 237 --NotaryReqData 238 messageImprint MessageImprint, 239 --if the data field in NotaryReqData is MessageImprint, this 240 --must contain that same value, otherwise it contains a hash of 241 --the data field in NotaryReqData using the hash algorithm 242 --specified in the signatureAlgorithm parameter 243 signature BIT STRING OPTIONAL, 244 --must be present if service field of notaryReqInfo is npd or nb 245 --must be the same value as the signature field in NotaryReq 246 policy PolicyInformation, 247 status PKIStatusInfo, 248 time NotaryTime, 249 signatureAlgorithm AlgorithmIdentifier, 250 certId CertId, 251 --must refer to the NA�s public verification certificate 252 certs SEQUENCE OF Certificate OPTIONAL, 253 --if present, must indicate the chain of trust used to verify the 254 --signature 255 crls SEQUENCE OF CertificateList OPTIONAL 256 } 258 NotaryTime ::= CHOICE { 259 genTime GeneralizedTime, 260 timeStampToken TimeStampToken } 262 PKIStatusInfo is defined in Section 3.2.3 of PKIX Part 3 [PKIX3]. If 263 the PKIStatus field has value �waiting� (3), then this token is a 264 receipt, as defined in Section 2. Otherwise, the status field is 265 present to indicate whether or not the notary request was fulfilled and, 266 if not, the reason it was rejected. A valid NotaryToken will have a 267 PKIStatus field with value �granted� (0). 269 CertId is defined in Section 3.2.4 of PKIX Part 3 [PKIX3]. 271 The crls field (if present) should contain a sequence of certificate and 272 authority revocation lists that is sufficient to verify the chain of 273 trust indicated in the certs field. 275 The signature, certs and crls fields are included as OPTIONAL. They 276 should be present, when policy dictates, for use as supplementary 277 evidence when resolving possible disputes. Dispute resolution would 279 most likely be handled by one or more humans, in an off-line 280 environment, and is beyond the scope of this document. 282 6. Notary Protocol Using Email 284 This section specifies a means for conveying ASN.1-encoded messages 285 for the protocol exchanges described in Section 4 via Internet mail. 287 A simple MIME object is specified as follows. 289 Content-Type: application/x-pkix6 290 Content-Transfer-Encoding: base64 292 <> 294 This MIME object can be sent and received using MIME processing engines 295 and provides a simple Internet mail transport for PKIX-6 messages. 297 7. Security Considerations 299 When designing a notary service, the following considerations have been 300 identified that have an impact upon the validity or �trust� in the 301 notary token. 303 1. The requester�s key is compromised and the corresponding 304 certificate is revoked before the notary acts upon the request. 305 The notary is required to validate appropriate information 306 within the request before it constructs the notary token. It is 307 therefore mandated that the NA have access to current 308 information regarding certificate status. In this situation, 309 the notarization would not occur. 311 2. The requester�s key is compromised and the corresponding 312 certificate is revoked after the notary acts upon the request. 313 This is not a concern to the NA once the notary has constructed 314 the token, as long as the compromise date in the CRL is not 315 before the time of notarization. If it is, this situation 316 would have to be handled by off-line, possibly human-aided, 317 means specific to the situation at hand. 319 3. The notary�s private key is compromised and the corresponding 320 certificate is revoked. In this case, any token signed by the 321 notary cannot be trusted. For this reason, it is imperative 322 that the notary�s key be guarded with proper security and 323 controls in order to minimize the possibility of compromise. 324 Nevertheless, in case the private key does become compromised, 325 an audit trail of all the tokens generated by the NA should be 326 kept as a means to help discriminate between genuine and false 327 tokens. 329 4. The NA signing key must be of a sufficient length to allow for 330 a sufficiently long lifetime. Even if this is done, the key 331 will have a finite lifetime. Thus, any token signed by the NA 332 should be time stamped again at a later date to renew the trust 333 that exists in the NA�s signature. 335 8. References 337 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 338 Non-Repudiation Framework. 340 [PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, �Internet Public Key 341 Infrastructure, Part I: X.509 Certificate and CRL Profile,� draft- 342 ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress). 344 [PKIX3] C. Adams, S. Farrell, �Internet Public Key Infrastructure, Part 345 III: Certificate Management Protocols,� draft-ietf-pkix-ipki3cmp- 346 0X.txt, 1997 (work in progress). 348 [PKIX5] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, �Internet Public 349 Key Infrastructure, Part V: Time Stamp Protocols,� draft-ietf-pkix- 350 ipki5tsp-00.txt, 1997 (work in progress). 352 9. Authors� Addresses 354 Carlisle Adams 355 Entrust Technologies 356 750 Heron Road, Suite 800 357 Ottawa, Ontario 358 K1V 1A7 359 CANADA 360 cadams@entrust.com 362 Robert Zuccherato 363 Entrust Technologies 364 750 Heron Road, Suite 800 365 Ottawa, Ontario 366 K1V 1A7 367 CANADA 368 robert.zuccherato@entrust.com 370 APPENDIX A - Storage of Data and Token 372 A notary token is useless without the data to which it applies. For 373 this reason tokens and their related data must be securely stored 374 together. The change of a single bit in either the data or the token 375 renders the entire notarization process for that data meaningless. 376 Storage of tokens and data in a secure (e.g., tamper proof) environment 377 is strongly recommended. 379 When data and notary tokens are stored together, the following ASN.1 380 data type may be used. 382 DataAndToken ::= SEQUENCE { 383 message Message, 384 notaryToken NotaryToken } 386 Note that this object does not need to be signed, as the notary token 387 already verifies the signature on the message. Any supplementary 388 information whose integrity needs to be protected should be part of 389 the message or token. 391 APPENDIX B - Extending the Life of a Signature 393 We present an example of a possible use of this general notary service. 394 It produces a stand-alone token that can be used to extend the life of a 395 signature. This example assumes that we have total trust in the Notary 396 Authority. 398 Signature algorithms and keys have a definite lifetime. Therefore, 399 signatures have a definite lifetime. The Notary Authority can be used 400 to extend the lifetime of a signature. 402 In order to extend the lifetime of a signature in this way, the 403 following technique may be used. 405 A) The signature needs to be notarized. 407 1) The signed message is presented to the Notary in the data 408 field of NotaryReqInfo under service type nd and an appropriate 409 policy. 411 2) The Notary verifies that the signature and verification key are 412 valid at that time by checking expiry dates, CRLs and ARLs, and 413 returns a NotaryToken. 415 B) The notarized signature must be verified. 417 1) The signature of the Notary in NotaryToken shall be verified 418 using the Notary�s valid verification key. 420 In this situation the signer�s signing key (and therefore, its 421 signature) is only valid until some specified time T1. The NA�s 422 signing key (and therefore, its signature) is valid until some specified 423 time T2 that is (usually) after time T1. Without notarization, the 424 signer�s signature would only be valid until time T1. With 425 notarization, the signer�s signature remains valid until time T2, 427 regardless of subsequent revocation or expiry at time T1. 429 If the signature of the NA is valid, the trust we have in the NA allows 430 us to conclude that the original signature on the data was valid at 431 the time included in the notaryInfo field of the NotaryToken. Notice 432 that in this example the validity of the original signature can be 433 confirmed from the verification of one signature (the NA�s) instead of 434 two signatures (the Time Stamp Authority�s and the original), but at the 435 cost of putting more trust in the Trusted Third Party.