idnits 2.17.1 draft-ietf-pkix-warranty-extn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 3) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 2004) is 7314 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? 'RFC2119' on line 41 looks like a reference -- Missing reference section? 'URI' on line 136 looks like a reference -- Missing reference section? 'RFC2396' on line 195 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force D. Linsenbardt SPYRUS 2 Internet-Draft S. Pontius SPYRUS 3 October 2003 A. Sturgeon SPYRUS 4 Expires in April 2004 6 Internet X.509 Public Key Infrastructure 7 Warranty Certificate Extension 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a certificate extension to explicitly state 33 the warranty offered by a Certificate Authority (CA) for the 34 certificate containing the extension. 36 Conventions Used In This Document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 Copyright (c) The Internet Society (2003). All rights reserved. 44 1. Introduction 46 The warranty certificate extension identifies the warranty policy 47 associated with a X.509 public key certificate [X.509-97, PROFILE]. 48 Often the Certificate Authority (CA) will obtain an insurance policy 49 to ensure coverage of the warranty. 51 The certificate warranty provides an extended monetary coverage for 52 the end entities. The certificate warranty primarily concerns the use, 53 storage, and reliance on a certificate by a subscriber, a relying 54 party, and the CA. It is common for a CA to establish reliance limits 55 on the use of a certificate. It is not uncommon for a CA to attempt 56 through contractual means to exclude its liability entirely. However, 57 this has the effect of undermining the confidence that commerce 58 requires to gainfully use certificates. 60 Alternatively a CA may provide extended coverage for the use of the 61 certificate. Usually, the subscriber pays for the extended warranty 62 coverage. In turn, subscribers are covered by an appropriately drafted 63 insurance policy. The certificate warranty is backed by an insurance 64 policy issued by a licensed insurance company, which results in a 65 financial backing that is far greater than that of the CA. This extra 66 financial backing provides a further element of confidence necessary to 67 encourage the use of certificates in commerce. 69 A relying party that has a warranty from a CA may obtain compensation 70 from a CA depending on the conditions for such compensation expressed 71 in either the CA's Certificate Policy or the CA's insurance policy, or 72 both. Evidence of an extended warranty, provided through the 73 certificate extension, will give the relying party additional 74 confidence that compensation is possible, and will therefore further 75 enhance trust in the process. Risk for a non-subscriber relying party 76 may be reduced by the presence of a warranty extension with an explicit 77 warranty stated. The warranty extension allows this aspect of risk 78 management to be automated. 80 When a certificate contains a warranty certificate extension, the 81 extension MUST be non-critical, and it MUST contain either a NULL to 82 indicate that no warranty is provided or base warranty data to 83 indicate that a warranty is provided. The extension MAY contain 84 optional qualifiers. 86 2. Warranty Extension Format 88 Like all X.509 certificate extensions, the warranty certificate 89 extension is defined using ASN.1 [X.208-88, X.209-88]. 91 The non-critical warranty extension is identified by 92 id-pe-warranty. 94 PKIX Object Identifier Registry 95 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 96 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 98 PKIX Arcs 99 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } -- modules 100 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } -- private 101 certificate extensions 103 PKIX modules 104 id-mod-warranty-extn OBJECT IDENTIFIER ::= { id-mod 27 } 106 id-pe-warranty OBJECT IDENTIFIER ::= { id-pe 16 } 108 A non-null warranty always includes a base warranty. The warranty 109 information includes the period during which the warranty applies, a 110 warranty value, and a warranty type. The warranty type tells the 111 warranty limit against claims. The extension definition 112 supports two alternatives: aggregated and per-transaction. With 113 aggregation, claims are fulfilled until a ceiling value is reached. 114 After that, no further claims are fulfilled. With per-transaction, a 115 ceiling value is imposed on each claim, but each transaction is 116 considered independently. 118 The warranty extension permits inclusion of two optional warranty 119 qualifiers. The first qualifier provides extended warranty information. 120 The second qualifier provides a pointer to the warranty terms and 121 conditions. 123 When present, the extended warranty information provides information 124 about coverage beyond the scope of the base warranty. Like the base 125 warranty information, the extended warranty information includes the 126 period during which the warranty applies, a warranty value, and a 127 warranty type. 129 When present, the terms and conditions pointer provides a reference to 130 a document containing the terms and conditions associated with the 131 warranty. The document may be a Certificate Policy that contains this 132 information, or it may be a document specifically about the warranty. 133 It may also be a Relying Party Agreement. The pointer is always a 134 uniform resource locator (URL). The URL MUST be a non-relative URL 135 using the http scheme. The URL MUST follow the URL syntax and encoding 136 rules specified in RFC 2396 [URI]. 138 2.1. Warranty Extension Syntax 140 The syntax for the warranty extension is: 142 Warranty ::= CHOICE { 143 none NULL, -- No warranty provided 144 wData WarrantyData } -- Explicit warranty 146 WarrantyData ::= SEQUENCE { 147 base WarrantyInfo, 148 extended WarrantyInfo OPTIONAL, 149 tcURL TermsAndConditionsURL OPTIONAL } 151 WarrantyInfo ::= SEQUENCE { 152 validity WarrantyValidityPeriod, 153 amount CurrencyAmount, 154 wType WarrantyType } 156 WarrantyValidityPeriod ::= CHOICE { 157 sameAsCertificate NULL, 158 explicitPeriod ValidityPeriod } 160 ValidityPeriod ::= SEQUENCE { 161 notBefore GeneralizedTime, 162 notAfter GeneralizedTime } 164 -- CurrencyAmount specifies the currency and a monetary value. 165 -- Currency codes are defined in ISO 4217. The monetary value 166 -- is: amount / (10 ** amtExp10), and the exponent MUST be the 167 -- minor unit of currency specified in ISO 4217. 169 CurrencyAmount ::= SEQUENCE { 170 currency INTEGER (1..999), 171 amount INTEGER (0..MAX), 172 amtExp10 INTEGER (0..MAX) } 174 WarrantyType ::= INTEGER { 175 aggregated (0), 176 perTransaction (1) } 178 TermsAndConditionsURL ::= IA5String -- MUST use http scheme 180 2.2. Warranty Extension Semantics 182 Warranty is a CHOICE; it is represented either by NULL or 183 WarrantyData. If the CA selects NULL, then the CA is explicitly 184 stating that no warranty is provided. If the CA selects WarrantyData, 185 then the CA is explicitly stating that a warranty is provided, and the 186 fields within the WarrantyData type MUST provide details about the 187 warranty that is provided. 189 WarrantyData MUST contain information about the base warranty. 190 WarrantyData MAY contain information about an extended warranty. Both 191 base warranty and extended warranty information is provided using the 192 WarrantyInfo type. WarrantyData MAY contain a URL that points to the 193 terms and conditions of the warranty. The URL is provided using the 194 TermsAndConditionsURL type, which is an IA5 string. The IA5String MUST 195 contain a URI [RFC2396] using the http scheme, such as 196 "http://www.example.com/warranty/t_and_c.html". 198 WarrantyInfo MUST contain the warranty validity period, the currency 199 amount of the warranty, and the type of warranty. The warranty 200 validity period is provided using the WarrantyValidityPeriod type. 201 The currency amount of the warranty is provided using the 202 CurrencyAmount type. The type of warranty is provided using the 203 WarrantyType type. 205 WarrantyValidityPeriod is a CHOICE; it is represented either by NULL 206 or ValidityPeriod. If the CA selects NULL, then the validity period 207 of the warranty MUST be exactly the same as the validity period of the 208 certificate. If the CA selects ValidityPeriod, then the CA is 209 explicitly stating a warranty validity period that is different than 210 the validity period of the certificate. If the warranty validity 211 period and the certificate validity period are the same, then the CA 212 MUST select the NULL choice. The validity periods are expected to be 213 the same in the vast majority of the cases. ValidityPeriod is a 214 SEQUENCE of two GeneralizedTime values. The first (notBefore) 215 GeneralizedTime value MUST indicate the date and time that the warranty 216 become valid, and the second (notAfter) GeneralizedTime value MUST 217 indicate the date and time that the warranty expires. 219 CurrencyAmount is a SEQUENCE if three integers. Together the integers 220 specify the currency and a monetary value. The first integer 221 (currency) MUST indicate the currency using one of the currency codes 222 defined in ISO 4217. The second integer (amount) MUST indicate the 223 value of the warranty. The third integer (amtExp10) MUST indicate the 224 correct placement of the decimal point in the monetary value, and it 225 MUST be the minor unit of currency specified in ISO 4217. For example 226 $48,525.50 (in US dollars) is represented as: 227 currency = 840 228 amount = 4852550 229 amtExp10 = 2 231 WarrantyType is an integer. A value of zero indicates that claims 232 against the warranty will be aggregated, and once the value of 233 fulfilled claims reaches the warranty currency amount, then no further 234 claim will be fulfilled. A value of one indicates that each claim is 235 handled independently, but no individual claim can exceed the warranty 236 currency amount. The CA MUST select either zero or one for this 237 integer value. 239 3. Security Considerations 241 The procedures and practices employed by the CA MUST ensure that the 242 correct values for the warranty are inserted in each certificate that is 243 issued. Relying parties and users may accept or reject a particular 244 certificate for an intended use based on the information provided in 245 warranty extension. Incorrect representation of the actual warranty 246 may result in otherwise avoidable warranty claims for the CA. 248 4. IANA Considerations 250 Certificate extensions and extended key usage values are identified 251 by object identifiers (OIDs). The OIDs used in this document are 252 derived from X.509 [X.509]. No further action by the IANA is 253 necessary for this document or any anticipated updates. 255 5. Normative References 257 ISO 4217 ISO. "Codes for the Representation of Currencies and 258 Funds", ISO 4217. 1995. 260 PROFILE Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 261 X.509 Public Key Infrastructure: Certificate and CRL 262 Profile", RFC 3280, May 2002. 264 URI Berners-Lee, T., Fielding, R., Irving, U.C., and L. 265 Masinter. "Uniform Resource Identifiers (URI): Generic 266 Syntax", RFC 2396, August 1998. 268 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 269 Syntax Notation One (ASN.1). 1988. 271 X.209-88 CCITT. Recommendation X.209: Specification of Basic 272 Encoding Rules for Abstract Syntax Notation One (ASN.1). 273 1988. 275 6. Informative References 277 X.509-97 ITU-T. Recommendation X.509: The Directory - 278 Authentication Framework. 1997. 280 7. ASN.1 Module 282 WarrantyExtn 283 { iso(1) identified-organization(3) dod(6) internet(1) 284 security(5) mechanisms(5) pkix(7) id-mod(0) 285 id-mod-warranty-extn(27) } 287 DEFINITIONS IMPLICIT TAGS ::= 288 BEGIN 290 -- OID Arcs 292 id-pe OBJECT IDENTIFIER ::= 293 { iso(1) identified-organization(3) dod(6) internet(1) 294 security(5) mechanisms(5) pkix(7) 1 } 296 -- Warranty Extension 298 id-pe-warranty-extn OBJECT IDENTIFIER ::= { id-pe 16 } 300 Warranty ::= CHOICE { 301 none NULL, -- No warranty provided 302 wData WarrantyData } -- Explicit warranty 304 WarrantyData ::= SEQUENCE { 305 base WarrantyInfo, 306 extended WarrantyInfo OPTIONAL, 307 tcURL TermsAndConditionsURL OPTIONAL } 309 WarrantyInfo ::= SEQUENCE { 310 validity WarrantyValidityPeriod, 311 amount CurrencyAmount, 312 wType WarrantyType } 314 WarrantyValidityPeriod ::= CHOICE { 315 sameAsCertificate NULL, 316 explicitPeriod ValidityPeriod } 318 ValidityPeriod ::= SEQUENCE { 319 notBefore GeneralizedTime, 320 notAfter GeneralizedTime } 322 -- CurrencyAmount specifies the currency and a monetary value. 323 -- Currency codes are defined in ISO 4217. The monetary value 325 -- is: amount / (10 ** amtExp10), and the exponent MUST be the 326 -- minor unit of currency specified in ISO 4217. 328 CurrencyAmount ::= SEQUENCE { 329 currency INTEGER (1..999), 330 amount INTEGER (0..MAX), 331 amtExp10 INTEGER (0..MAX) } 333 WarrantyType ::= INTEGER { 334 aggregated (0), 335 perTransaction (1) } 337 TermsAndConditionsURL ::= IA5String 339 END 341 Acknowledgements 342 This Internet-Draft was developed with the expertise and support of Russ 343 Housley, Vigil Security LLC, and Dr. Adrian McCullagh, Freehills Australia. 345 Author's Address 347 Duane Linsenbardt 348 SPYRUS 349 2355 Oakland Road 350 Suite 1 351 San Jose CA 95131 352 USA 353 dlinsenbardt@spyrus.com 354 Sue Pontius 355 SPYRUS 356 2355 Oakland Road 357 Suite 1 358 San Jose CA 95131 359 USA 360 spontius@spyrus.com 362 Alice Sturgeon 363 SPYRUS 364 Suite 1502, 222 Queen St., 365 Ottawa ON K0A 2T0 366 Canada 367 asturgeon@spyrus.com 369 Person & email address to contact for further information: 370 Alice Sturgeon 372 Full Copyright Statement 374 Copyright (C) The Internet Society 2003. All Rights Reserved. 376 This document and translations of it may be copied and furnished to 377 others, and derivative works that comment on or otherwise explain it 378 or assist in its implementation may be prepared, copied, published and 379 distributed, in whole or in part, without restriction of any kind, 380 provided that the above copyright notice and this paragraph are 381 included on all such copies and derivative works. However, this 382 document itself may not be modified in any way, such as by removing 383 the copyright notice or references to the Internet Society or other 384 Internet organizations, except as needed for the purpose of developing 385 Internet standards in which case the procedures for copyrights defined 386 in the Internet Standards process must be followed, or as required to 387 translate it into languages other than English. 389 The limited permissions granted above are perpetual and will not be 390 revoked by the Internet Society or its successors or assigns. 392 This document and the information contained herein is provided on an 393 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 394 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 395 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 396 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 397 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Acknowledgement 401 Funding for the RFC Editor function is currently provided by the 402 Internet Society. 404 Expires in April 2004