RFC 4059

Internet X.509 Public Key Infrastructure Warranty Certificate Extension

📅 published May 2005, from ietf

RFC 4059 💖 Internet X.509 Public Key Infrastructure Warranty Certificate Extension

okay bestie, here's the header rundown 🎀

  • Stream: Network Working Group 🦋
  • Authors: D. Linsenbardt, S. Pontius, and A. Sturgeon, all from SPYRUS 💅
  • Category: Informational 🌸
  • Date: May 2005 ⭐
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🫶

Status of This Memo ✨

this memo gives information to the Internet community 💜 it does NOT specify an Internet standard of any kind, so it's not a rulebook for protocols 🙈 and distribution of it is unlimited 🌈

Copyright (C) The Internet Society (2005) 🎀

Abstract

this doc describes a certificate extension that lets a Certificate Authority (CA) explicitly state the warranty it offers for the certificate that contains the extension 💅✨

1. Introduction ✨

okay so the warranty certificate extension tells you which warranty policy goes with an X.509 public key certificate [X.509-97, PROFILE] 🔐 and often the CA gets an insurance policy to cover that warranty 🛡️

the certificate warranty gives extended monetary coverage to end entities 💖 it mostly cares about how a certificate gets used, stored, and relied on by a subscriber, a relying party, and the CA 👑 it's super common for a CA to set reliance limits on a certificate 🙄 and it's not uncommon for a CA to try to contractually exclude its liability entirely 💀 but honestly that's giving "nobody trusts this," and commerce needs trust to actually use certificates 😭

the other option is that a CA provides extended coverage for using the certificate 🎀 usually the subscriber pays for that extended warranty 💸 and the subscribers are covered by an appropriately drafted insurance policy 🫶 the warranty is backed by a policy from a licensed insurance company, which means the financial backing is way bigger than the CA's own 🔥 that extra backing adds another layer of confidence that makes people more likely to use certificates in commerce 🧚

a relying party with a warranty from a CA may get compensation from the CA, depending on the conditions for that compensation written in the CA's Certificate Policy, the CA's insurance policy, or both 🌸 seeing an extended warranty through the certificate extension gives the relying party more confidence that compensation is possible, which boosts trust in the whole process 💜 for a non-subscriber relying party, risk can go down when the extension is there with an explicit warranty stated 👑 and the warranty extension lets this part of risk management get automated 🤖✨

when a certificate has a warranty certificate extension, the extension MUST be non-critical, and it MUST contain either a NULL to say no warranty is provided, or base warranty data to say a warranty is provided 🎀 it MAY also 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 }

okay so a non-null warranty ALWAYS includes a base warranty 💖 wait, I need to fix that: the original says "always", and that's what I mean, a non-null warranty always includes a base warranty 🎀 the warranty info covers the period the warranty applies to, a warranty value, and a warranty type 💜 the warranty type tells you the limit on claims 🔥 the extension supports two options, aggregated and per-transaction 👑 with aggregation, claims get fulfilled until a ceiling value is reached, and after that no more claims get fulfilled 😭 with per-transaction, each claim has a ceiling value, but every transaction is looked at on its own 🧚

the warranty extension lets you include two optional warranty qualifiers 🌸 the first one gives extended warranty information, and the second one points to the warranty terms and conditions 💅

when it's there, the extended warranty information covers stuff beyond the base warranty 🌈 like the base info, it includes the period the warranty applies to, a warranty value, and a warranty type ✨

when it's there, the terms and conditions pointer references a document with the terms and conditions for the warranty 📚 that doc can be a Certificate Policy with that info, 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 🙈 and the URL MUST follow the URL syntax and encoding rules 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  }

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

(part 2 picks up with Section 2.2, Section 3, and Section 4 🦋✨)

5. ASN.1 Module 🎀

okay so this is the part where the spec gets super formal and starts speaking pure ASN.1, but bestie, it's still giving structure ✨ Here's the whole module, copied exactly, because the bits have to be perfect:

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  }

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

Quick vibe check on the important bit 💅: the exponent in CurrencyAmount MUST be the minor unit of the currency per [ISO4217]. That's a hard rule, no wiggle room 🫶

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. 🍓

Acknowledgements 🫶

This document was developed with the expertise and support of Russ Housley, Vigil Security LLC, and Dr. Adrian McCullagh, Freehills Australia. Huge thanks to them, literally the dream team 👑

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

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.

📦 where this page comes from