Certificate Limitation Policy

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2017-07-02
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group
Internet-Draft                                              July 1, 2017
Intended status: Experimental
Expires: January 2, 2018

                     Certificate Limitation Policy


   The document provides a specification of the application-level trust
   model.  Being provided at the application level, the limitations of
   trust can be distributed separately using cryptographically protected
   format instead of hardcoding the checks into the application itself.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 2, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.

                         Expires January 2, 2018                [Page 1]
Internet-Draft        Certificate Limitation Policy            July 2017

1.  Introduction

   Binary trust model standardized as a set of trusted anchors and CRLs/
   OCSP services does not cover all corner cases in the modern crypto
   world.  There is a need in more differentiated limitations.  Some of
   them are suggested [1] by Google when it limits the usage of
   Symantec's certificates.  The CRL profile does not fit the purpose of
   such limitations.  The CRLs are issued by the same CAs that are
   subject to be limited.

   Currently the set of CAs trusted by OS can be used for the validation
   purposes.  In case when a large enough CA becomes untrusted, it
   cannot be deleted from the storage of trusted CAs because it may
   cause error of validation of many certificates.  The measures usually
   taken in such cases usually include application-level limitation of
   certificates lifetimes, refusing to accept EV-certificates in other
   way than DV, requirements to use Certificate Transparency, etc.

   This document suggests a cryptographically signed format dubbed
   Certificate Limitation Profile (CLP) designed for description of such
   limitations.  This format can be used by applications that use
   system-wide set of trust anchors for validating purposes or by
   applications with own wide enough set of trusted anchors in case when
   the trust anchor for the entity found misbehaving cannot be revoked.

   Currently the only way to provide such limitations is hard coding
   them in application itself.  Using of CLPs does not allow to
   completely avoid hard coding but allows to hard code only the minimal
   set of rarely changing data:

      the fact that application uses CLP

      the certificate to verify the signature under the CLP file

      minimal date of the CLP to be used for the current version of

   It will be possible to move the checks for the limitations to the
   external cryptographical libraries, such as OpenSSL, instead of
   checking them at the application level.

2.  Certificate Limitations Profile

   A proposed syntax and overall structure of CLP is very similar to the
   one defined for CRLs [2].  CertificateList ::= SEQUENCE { tbsCertList
   TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue
   BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, --
   if present, MUST be v1 signature AlgorithmIdentifier, issuer Name,

                         Expires January 2, 2018                [Page 2]
Internet-Draft        Certificate Limitation Policy            July 2017

   thisUpdate Time, limitedCertificates SEQUENCE OF SEQUENCE {
   userCertificate CertificateSerialNumber, sertificateIssuer Name,
   limitationDate Time, limitationPropagation Enum, fingerprint SEQUENCE
   { fingerprintAlgorithm AlgorithmIdentifier, fingerprintValue OCTET
Show full document text