idnits 2.17.00 (12 Aug 2021) /tmp/idnits8902/draft-ietf-pkix-warranty-extn-00.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 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 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'URL' on line 107 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Linsenbardt 3 Internet-Draft S. Pontius 4 April 2002 SPYRUS 5 Expires: October 2002 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 a 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 1. Introduction 44 The warranty certificate extension identifies the warranty policy 45 associated with a X.509 public key certificate [X.509-97, PROFILE]. 46 Often the Certificate Authority (CA) will obtain an insurance policy 47 to ensure coverage of the warranty. 49 The certificate warranty provides an extended monetary coverage for 50 the legal liability of the CA, in favor of the subscriber. The 51 certificate warranty primarily concerns the use, storage, and reliance 52 on a certificate by a third party and the CA. It is common for a CA 53 to limit liability by establishing reliance limits on the use of a 54 certificate. It is not uncommon for a CA to attempt through 55 contractual means to exclude its liability entirely. However, this 56 has the effect of undermining the confidence that commerce requires to 57 gainfully use certificates. 59 Alternatively a CA may provide extended liability coverage for the use 60 of the certificate. Usually, the subscriber pays for the extended 61 warranty coverage. In turn, subscribers are covered by an 62 appropriately drafted insurance policy. The certificate warranty is 63 backed by an insurance policy issued by a licensed insurance company, 64 which results in a financial backing that is far greater than that of 65 the CA. This extra financial backing provides a further element of 66 confidence necessary to encourage the use of certificates in commerce. 68 When a certificate contains a warranty certificate extension, the 69 extension MUST be non-critical, and it MUST contain base warranty 70 data. The extension MAY contain optional qualifiers. 72 2. Warranty Extension Format 74 Like all X.509 certificate extensions, the warranty certificate 75 extension is defined using ASN.1 [X.208-88, X.209-88]. 77 The non-critical warranty extension is identified by 78 id-pe-warrantyData. 80 id-pe-warrantyData OBJECT IDENTIFIER ::= { id-pe <> } 82 The warranty always includes a base warranty. The warranty 83 information includes the period during which the warranty applies, a 84 warranty value, and a warranty type. The warranty type tells the 85 liability limitations against claims. The extension definition 86 supports two alternatives: aggregated and per-transaction. With 87 aggregation, claims are fulfilled until a ceiling value is reached. 88 After that, no further claims are fulfilled. With per-transaction, a 89 ceiling value is imposed on each claim, but each transaction is 90 considered independently. 92 The warranty extension permits inclusion of two optional warranty 93 qualifiers. The first qualifier provides extended warranty information. 94 The second qualifier provides a pointer to the warranty terms and 95 conditions. 97 When present, the extended warranty information provides information 98 about coverage beyond the scope of the base warranty. Like the base 99 warranty information, the extended warranty information includes 100 period during which the warranty applies, a warranty value, and a 101 warranty type. 103 When present, the terms and conditions pointer provides a reference to 104 a document containing the terms and conditions associated with the 105 warranty. The pointer is always a uniform resource locator (URL). 106 The URL MUST be a non-relative URL, and it MUST follow the URL syntax 107 and encoding rules specified in RFC 1738 [URL]. 109 2.1. Warranty Extension Syntax 111 The syntax for the warranty extension is: 113 Warranty ::= CHOICE { 114 none NULL, -- No warranty provided 115 wData WarrantyData } -- Explicit warranty 117 WarrantyData ::= SEQUENCE { 118 base WarrantyInfo, 119 extended WarrantyInfo OPTIONAL, 120 tcURL TermsAndConditionsURL OPTIONAL } 122 WarrantyInfo ::= SEQUENCE { 123 validity WarrantyValidityPeriod, 124 amount CurrencyAmount, 125 wType WarrantyType } 127 WarrantyValidityPeriod ::= CHOICE { 128 sameAsCertificate NULL, 129 explicitPeriod ValidityPeriod } 131 ValidityPeriod ::= SEQUENCE { 132 notBefore GeneralizedTime, 133 notAfter GeneralizedTime } 135 -- CurrencyAmount specifies the currency and a monetary value. 136 -- Currency codes are defined in ISO 4217. The monetary value 137 -- is: amount * (10 ** amtExp10), and the exponent MUST be the 138 -- minor unit of currency specified in ISO 4217. 140 CurrencyAmount ::= SEQUENCE { 141 currency INTEGER (1..999), 142 amount INTEGER (0..MAX), 143 amtExp10 INTEGER (0..MAX) } 145 WarrantyType ::= INTEGER { 146 aggregated (0), 147 perTransaction (1) } 149 TermsAndConditionsURL ::= IA5String 151 2.2. Warranty Extension Semantics 153 Warranty is a CHOICE; it is represented either by NULL or 154 WarrantyData. If the CA selects NULL, then the CA is explicitly 155 stating that no warranty is provided. If the CA selects WarrantyData, 156 then the CA is explicitly stating that a warranty is provided, and the 157 fields within the WarrantyData type MUST provide details about the 158 warranty that is provided. 160 WarrantyData MUST contain information about the base warranty. 161 WarrantyData MAY contain information about an extended warranty. Both 162 base warranty and extended warranty information is provided using the 163 WarrantyInfo type. WarrantyData MAY contain a URL that points to the 164 terms and conditions of the warranty. The URL is provided using the 165 TermsAndConditionsURL type, which is an IA5 string. 167 WarrantyInfo MUST contain the warranty validity period, the currency 168 amount of the warranty, and the type of warranty. The warranty 169 validity period is provided using the WarrantyValidityPeriod type. 170 The currency amount of the warranty is provided using the 171 CurrencyAmount type. The type of warranty is provided using the 172 WarrantyType type. 174 WarrantyValidityPeriod is a CHOICE; it is represented either by NULL 175 or ValidityPeriod. If the CA selects NULL, then the validity period 176 of the warranty MUST be exactly the same as the validity period of the 177 certificate. If the CA selects ValidityPeriod, then the CA is 178 explicitly stating a warranty validity period that is different than 179 the validity period of the certificate. If the warranty validity 180 period and the certificate validity period are the same, then the CA 181 MUST select the NULL choice. The validity periods are expected to be 182 the same in the vast majority of the cases. 184 ValidityPeriod is a SEQUENCE of two GeneralizedTime values. The first 185 (notBefore) GeneralizedTime value MUST indicate the date and time that 186 the warranty become valid, and the second (notAfter) GeneralizedTime 187 value MUST indicate the date and time that the warranty expires. 189 CurrencyAmount is a SEQUENCE if three integers. Together the integers 190 specify the currency and a monetary value. The first integer 191 (currency) MUST indicate the currency using one of the currency codes 192 defined in ISO 4217. The second integer (amount) MUST indicate the 193 value of the warranty. The third integer (amtExp10) MUST indicate the 194 correct placement of the decimal point in the monetary value, and it 195 MUST be the minor unit of currency specified in ISO 4217. For example 196 $48,525.50 (in US dollars) is represented as: 197 currency = 840 198 amount = 4852550 199 amtExp10 = 2 201 WarrantyType is an integer. A value of zero indicates that claims 202 against the warranty will be aggregated, and once the value of 203 fulfilled claims reaches the warranty currency amount, then no further 204 claim will be fulfilled. A value of one indicates that each claim is 205 handled independently, but no individual claim can exceed the warranty 206 currency amount. The CA MUST select either zero or one for this 207 integer value. 209 3. Security Considerations 211 The procedures and practices employed by the CA MUST ensure that the 212 correct values for the warranty are inserted in each certificate that is 213 issued. Relying parties and users may accept or reject a particular 214 certificate for an intended use based on the information provided in 215 warranty extension. Incorrect representation of the actual warranty 216 may result in unexpected liabilities for the CA. 218 4. References 220 ISO 4217 ISO. Codes for the Representation of Currencies and 221 Funds," ISO 4217. 1995. 223 PROFILE Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 224 X.509 Public Key Infrastructure: Certificate and CRL 225 Profile", RFC 2459, January 1999. 227 URL Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform 228 Resource Locators (URL)", RFC 1738, December 1994. 230 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 231 Syntax Notation One (ASN.1). 1988. 233 X.209-88 CCITT. Recommendation X.209: Specification of Basic 234 Encoding Rules for Abstract Syntax Notation One (ASN.1). 235 1988. 237 X.509-97 ITU-T. Recommendation X.509: The Directory - 238 Authentication Framework. 1997. 240 Acknowledgements 242 This Internet-Draft was developed with the expertise and support of Russ Housley, 243 RSA Laboratories, and Dr. Adrian McCullagh, Freehills Australia. 245 Author's Address 247 Duane Linsenbardt 248 Sue Pontius 249 SPYRUS 250 2355 Oakland Road 251 Suite 1 252 San Jose CA 95131 253 USA 254 dlinsenbardt@spyrus.com 255 spontius@spyrus.com 257 Person & email address to contact for further information: 258 Alice Sturgeon 259 Full Copyright Statement 261 Copyright (C) The Internet Society 2000. All Rights Reserved. 263 This document and translations of it may be copied and furnished to 264 others, and derivative works that comment on or otherwise explain it 265 or assist in its implementation may be prepared, copied, published and 266 distributed, in whole or in part, without restriction of any kind, 267 provided that the above copyright notice and this paragraph are 268 included on all such copies and derivative works. However, this 269 document itself may not be modified in any way, such as by removing 270 the copyright notice or references to the Internet Society or other 271 Internet organizations, except as needed for the purpose of developing 272 Internet standards in which case the procedures for copyrights defined 273 in the Internet Standards process must be followed, or as required to 274 translate it into languages other than English. 276 The limited permissions granted above are perpetual and will not be 277 revoked by the Internet Society or its successors or assigns. 279 This document and the information contained herein is provided on an 280 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 281 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 282 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 283 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 284 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 286 Acknowledgement 288 Funding for the RFC Editor function is currently provided by the 289 Internet Society.