summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4059.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4059.txt')
-rw-r--r--doc/rfc/rfc4059.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc4059.txt b/doc/rfc/rfc4059.txt
new file mode 100644
index 0000000..03708ef
--- /dev/null
+++ b/doc/rfc/rfc4059.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group D. Linsenbardt
+Request for Comments: 4059 S. Pontius
+Category: Informational A. Sturgeon
+ SPYRUS
+ May 2005
+
+ Internet X.509 Public Key Infrastructure
+ Warranty Certificate Extension
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes a certificate extension to explicitly state
+ the warranty offered by a Certificate Authority (CA) for the
+ certificate containing the extension.
+
+1. Introduction
+
+ The warranty certificate extension identifies the warranty policy
+ associated with a X.509 public key certificate [X.509-97, PROFILE].
+ Often the Certificate Authority (CA) will obtain an insurance policy
+ to ensure coverage of the warranty.
+
+ The certificate warranty provides an extended monetary coverage for
+ the end entities. The certificate warranty primarily concerns the
+ use, storage, and reliance on a certificate by a subscriber, a
+ relying party, and the CA. It is common for a CA to establish
+ reliance limits on the use of a certificate. It is not uncommon for
+ a CA to attempt through contractual means to exclude its liability
+ entirely. However, this undermines the confidence that commerce
+ requires to gainfully use certificates.
+
+ Alternatively a CA may provide extended coverage for the use of the
+ certificate. Usually, the subscriber pays for the extended warranty
+ coverage. In turn, subscribers are covered by an appropriately
+ drafted insurance policy. The certificate warranty is backed by an
+ insurance policy issued by a licensed insurance company, which
+ results in a financial backing that is far greater than that of the
+
+
+
+
+Linsenbardt, et al. Informational [Page 1]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+ CA. This extra financial backing provides a further element of
+ confidence necessary to encourage the use of certificates in
+ commerce.
+
+ A relying party that has a warranty from a CA may obtain compensation
+ from a CA depending on the conditions for such compensation expressed
+ in either the CA's Certificate Policy, the CA's insurance policy, or
+ both. Evidence of an extended warranty, provided through the
+ certificate extension, will give the relying party additional
+ confidence that compensation is possible, and therefore will enhance
+ trust in the process. Risk for a non-subscriber relying party may be
+ reduced by the presence of a warranty extension with an explicit
+ warranty stated. The warranty extension allows this aspect of risk
+ management to be automated.
+
+ When a certificate contains a warranty certificate extension, the
+ extension MUST be non-critical, and MUST contain either a NULL to
+ indicate that no warranty is provided or base warranty data to
+ indicate that a warranty is provided. The extension MAY contain
+ optional qualifiers.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Warranty Extension Format
+
+ Like all X.509 certificate extensions, the warranty certificate
+ extension is defined using ASN.1 [X.208-88, X.209-88].
+
+ The non-critical warranty extension is identified by id-pe-warranty.
+
+ PKIX Object Identifier Registry
+ id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+ PKIX Arcs
+ id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } -- modules
+ id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } -- private
+ certificate extensions
+
+ PKIX modules
+ id-mod-warranty-extn OBJECT IDENTIFIER ::= { id-mod 27 }
+
+ id-pe-warranty OBJECT IDENTIFIER ::= { id-pe 16 }
+
+
+
+
+Linsenbardt, et al. Informational [Page 2]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+ A non-null warranty always includes a base warranty. The warranty
+ information includes the period during which the warranty applies, a
+ warranty value, and a warranty type. The warranty type tells the
+ warranty limit against claims. The extension definition supports two
+ alternatives: aggregated and per-transaction. With aggregation,
+ claims are fulfilled until a ceiling value is reached. After that,
+ no further claims are fulfilled. With per-transaction, a ceiling
+ value is imposed on each claim, but each transaction is considered
+ independently.
+
+ The warranty extension permits inclusion of two optional warranty
+ qualifiers. The first qualifier provides extended warranty
+ information, the second provides a pointer to the warranty terms and
+ conditions.
+
+ When present, the extended warranty information provides information
+ about coverage beyond the scope of the base warranty. Like the base
+ warranty information, the extended warranty information includes the
+ period during which the warranty applies, a warranty value, and a
+ warranty type.
+
+ When present, the terms and conditions pointer provides a reference
+ to a document containing the terms and conditions associated with the
+ warranty. The document may be a Certificate Policy that contains
+ this information, a document specifically about the warranty, or a
+ Relying Party Agreement. The pointer is always a uniform resource
+ locator (URL). The URL MUST be a non-relative URL using the http
+ scheme. The URL MUST follow the URL syntax and encoding rules
+ specified in RFC 3986 [URI].
+
+2.1. Warranty Extension Syntax
+
+ The syntax for the warranty extension is:
+
+ Warranty ::= CHOICE {
+ none NULL, -- No warranty provided
+ wData WarrantyData } -- Explicit warranty
+
+ WarrantyData ::= SEQUENCE {
+ base WarrantyInfo,
+ extended WarrantyInfo OPTIONAL,
+ tcURL TermsAndConditionsURL OPTIONAL }
+
+ WarrantyInfo ::= SEQUENCE {
+ validity WarrantyValidityPeriod,
+ amount CurrencyAmount,
+ wType WarrantyType }
+
+
+
+
+Linsenbardt, et al. Informational [Page 3]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+ WarrantyValidityPeriod ::= CHOICE {
+ sameAsCertificate NULL,
+ explicitPeriod ValidityPeriod }
+
+ ValidityPeriod ::= SEQUENCE {
+ notBefore GeneralizedTime,
+ notAfter GeneralizedTime }
+
+ -- CurrencyAmount specifies the currency and a monetary value.
+ -- Currency codes are defined in [ISO4217]. The monetary value
+ -- is: amount / (10 ** amtExp10), and the exponent MUST be the
+ -- minor unit of currency specified in [ISO4217].
+
+ CurrencyAmount ::= SEQUENCE {
+ currency INTEGER (1..999),
+ amount INTEGER (0..MAX),
+ amtExp10 INTEGER (0..MAX) }
+
+ WarrantyType ::= INTEGER {
+ aggregated (0),
+ perTransaction (1) }
+
+ TermsAndConditionsURL ::= IA5String -- MUST use http scheme
+
+2.2. Warranty Extension Semantics
+
+ Warranty is a CHOICE; it is represented either by NULL or
+ WarrantyData. If the CA selects NULL, then the CA is explicitly
+ stating that no warranty is provided. If the CA selects
+ WarrantyData, then the CA is explicitly stating that a warranty is
+ provided, and the fields within the WarrantyData type MUST provide
+ details about that warranty.
+
+ WarrantyData MUST contain information about the base warranty.
+ WarrantyData MAY contain information about an extended warranty.
+ Both base warranty and extended warranty information is provided
+ using the WarrantyInfo type. WarrantyData MAY contain a URL that
+ points to the terms and conditions of the warranty. The URL is
+ provided using the TermsAndConditionsURL type, which is an IA5
+ string. The IA5String MUST contain a URI [URI] using the http
+ scheme, such as "http://www.example.com/warranty/t_and_c.html".
+
+ WarrantyInfo MUST contain the warranty validity period, the currency
+ amount of the warranty, and the type of warranty. The warranty
+ validity period is provided using the WarrantyValidityPeriod type.
+ The currency amount of the warranty is provided using the
+ CurrencyAmount type. The type of warranty is provided using the
+ WarrantyType type.
+
+
+
+Linsenbardt, et al. Informational [Page 4]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+ WarrantyValidityPeriod is a CHOICE; it is represented either by NULL
+ or ValidityPeriod. If the CA selects NULL, then the validity periods
+ of the warranty and the certificate MUST be exactly the same. If the
+ CA selects ValidityPeriod, then the CA is explicitly stating a
+ warranty validity period that is different than the validity period
+ of the certificate. If the validity periods of the warranty and the
+ certificate are the same, then the CA MUST select the NULL choice.
+ The validity periods are expected to be the same in the vast majority
+ of the cases. ValidityPeriod is a SEQUENCE of two GeneralizedTime
+ values. The first (notBefore) GeneralizedTime value MUST indicate
+ the date and time that the warranty becomes valid, and the second
+ (notAfter) GeneralizedTime value MUST indicate the date and time that
+ the warranty expires.
+
+ CurrencyAmount is a SEQUENCE of three integers which together specify
+ the currency and a monetary value. The first integer (currency) MUST
+ indicate the currency using one of the currency codes defined in
+ [ISO4217]. The second integer (amount) MUST indicate the value of
+ the warranty. The third integer (amtExp10) MUST indicate the correct
+ placement of the decimal point in the monetary value, and MUST be the
+ minor unit of currency specified in [ISO4217]. For example
+ $48,525.50 (in US dollars) is represented as:
+
+ currency = 840
+ amount = 4852550
+ amtExp10 = 2
+
+ WarrantyType is an integer. A value of zero indicates that claims
+ against the warranty will be aggregated, and once the value of
+ fulfilled claims reaches the warranty currency amount, then no
+ further claim will be fulfilled. A value of one indicates that each
+ claim is handled independently, but no individual claim can exceed
+ the warranty currency amount. The CA MUST select either zero or one
+ for this integer value.
+
+3. Security Considerations
+
+ The procedures and practices employed by the CA MUST ensure that the
+ correct values for the warranty are inserted in each issued
+ certificate. Relying parties and users may accept or reject a
+ particular certificate for an intended use based on the information
+ provided in warranty extension. Incorrect representation of the
+ actual warranty may result in otherwise avoidable warranty claims for
+ the CA.
+
+
+
+
+
+
+
+Linsenbardt, et al. Informational [Page 5]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+4. IANA Considerations
+
+ Certificate extensions and extended key usage values are identified
+ by object identifiers (OIDs). The OIDs used in this document are
+ derived from X.509 [X.509-97]. No further action by the IANA is
+ necessary for this document or any anticipated updates.
+
+5. ASN.1 Module
+
+ WarrantyExtn
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) id-mod(0)
+ id-mod-warranty-extn(27) }
+
+ DEFINITIONS IMPLICIT TAGS ::=
+ BEGIN
+
+
+ -- OID Arcs
+
+ id-pe OBJECT IDENTIFIER ::=
+ { iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) mechanisms(5) pkix(7) 1 }
+
+ -- Warranty Extension
+
+ id-pe-warranty-extn OBJECT IDENTIFIER ::= { id-pe 16 }
+
+ Warranty ::= CHOICE {
+ none NULL, -- No warranty provided
+ wData WarrantyData } -- Explicit warranty
+
+ WarrantyData ::= SEQUENCE {
+ base WarrantyInfo,
+ extended WarrantyInfo OPTIONAL,
+ tcURL TermsAndConditionsURL OPTIONAL }
+
+ WarrantyInfo ::= SEQUENCE {
+ validity WarrantyValidityPeriod,
+ amount CurrencyAmount,
+ wType WarrantyType }
+
+ WarrantyValidityPeriod ::= CHOICE {
+ sameAsCertificate NULL,
+ explicitPeriod ValidityPeriod }
+
+
+
+
+
+
+Linsenbardt, et al. Informational [Page 6]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+ ValidityPeriod ::= SEQUENCE {
+ notBefore GeneralizedTime,
+ notAfter GeneralizedTime }
+
+ -- CurrencyAmount specifies the currency and a monetary value.
+ -- Currency codes are defined in [ISO4217]. The monetary value
+ -- is: amount / (10 ** amtExp10), and the exponent MUST be the
+ -- minor unit of currency specified in [ISO4217].
+
+ CurrencyAmount ::= SEQUENCE {
+ currency INTEGER (1..999),
+ amount INTEGER (0..MAX),
+ amtExp10 INTEGER (0..MAX) }
+
+ WarrantyType ::= INTEGER {
+ aggregated (0),
+ perTransaction (1) }
+
+ TermsAndConditionsURL ::= IA5String
+
+ END
+
+6. Normative References
+
+ [ISO4217] ISO. "Codes for the Representation of Currencies and
+ Funds", ISO 4217. 1995.
+
+ [PROFILE] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and CRL
+ Profile", RFC 2459, January 1999.
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
+ Syntax Notation One (ASN.1). 1988.
+
+ [X.209-88] CCITT. Recommendation X.209: Specification of Basic
+ Encoding Rules for Abstract Syntax Notation One (ASN.1).
+ 1988.
+
+7. Informative References
+
+ [X.509-97] ITU-T. Recommendation X.509: The Directory-
+ Authentication Framework. 1997.
+
+
+
+
+
+Linsenbardt, et al. Informational [Page 7]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+Acknowledgements
+
+ This document was developed with the expertise and support of Russ
+ Housley, Vigil Security LLC, and Dr. Adrian McCullagh, Freehills
+ Australia.
+
+Authors' Addresses
+
+ Duane Linsenbardt
+ SPYRUS
+ 2355 Oakland Road
+ Suite 1
+ San Jose CA 95131
+ USA
+
+ EMail: dlinsenbardt@spyrus.com
+
+
+ Sue Pontius
+ SPYRUS
+ 2355 Oakland Road
+ Suite 1
+ San Jose CA 95131
+ USA
+
+ EMail: spontius@spyrus.com
+
+
+ Alice Sturgeon
+ SPYRUS
+ Suite 1502, 222 Queen St.,
+ Ottawa ON K0A 2T0
+ Canada
+
+ EMail: asturgeon@spyrus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Linsenbardt, et al. Informational [Page 8]
+
+RFC 4059 Warranty Certificate Extension May 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Linsenbardt, et al. Informational [Page 9]
+