Network Working Group
Internet-Draft TCI
Intended status: Experimental May 28, 2018
Expires: November 29, 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

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 November 29, 2018.

Copyright Notice

Copyright (c) 2018 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 ( 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.

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 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 or browsers 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:

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

   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version,
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time,
        limitedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             certificateIssuer       Name, 
             limitationDate          Time,
             limitationPropagation   Enum,
             fingerprint SEQUENCE {
                 fingerprintAlgorithm AlgorithmIdentifier,
                 fingerprintValue     OCTET STRING
                                  } OPTIONAL,
             limitations          Limitations,
                                } OPTIONAL,

   Limitations  ::=  SEQUENCE SIZE (1..MAX) OF Limitation

   Limitation  ::=  SEQUENCE  {
        limitID      OBJECT IDENTIFIER,
        LimitationValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the limitation type 
                    -- identified by limitID

A proposed syntax and overall structure of CLP is very similar to the one defined for CRLs.

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

The ASN.1 format of particular limitations is provided in the corresponding sections. Anywhere below the Time in ASN.1 notation is treated according to RFC 5280:

2.1. CLP fields

CLP has general structure similar to CRLs. The upper-level fields are:

2.2. CLP signature

The key used for signing the CLP files should have a special Key Usage value and/or an Extended Key Usage value.

2.3. CLP entry fields

Each entry in list contains the following fields:

and a subset of the following limitations:

The limitations are identified by OIDs

2.3.1. Limitations issuedNotAfter

When this limitation is present, any certificate matching the entry and issued after the specified date MUST NOT be trusted

The issuedNotAfter limitation is identified by OID TBA.

issuedNotAfter ::= SEQUENCE {
    IssuedNotAfter    Time
} trustNotAfter

When this limitation is present, any certificate matching the entry MUST NOT be trusted after the specified date.

The trustNotAfter limitation is identified by OID TBA.

trustNotAfter ::= SEQUENCE {
    TrustNotAfter    Time
} validityPeriod

When this limitation is present, no certificate matching the entry should be treated as valid after specified period from its validFrom.

The validityPeriod is measured in days.

The validityPeriod limitation is identified by OID TBA.

validityPeriod ::= SEQUENCE {
    Days INTEGER
} ignoredX509Extensions

When this limitation is present, the extensions listed in this element should be ignored for the matching certificate.

The ignoredX509Extensions limitation is identified by OID TBA.

ignoredX509Extensions :: = SEQUENCE SIZE (1..MAX) OF ExtenID
ExtenID :: = OBJECT IDENTIFIER requiredX509extensions

When this limitation is present, the extensions listed in this element should be present for the matching certificate.

The requiredX509extensions limitation is identified by OID TBA.

requiredX509extensions :: = SEQUENCE SIZE (1..MAX) OF ExtenID
ExtenID :: = OBJECT IDENTIFIER requiredNativeChecking

When this limitation is present, it specifies that the certificates issued by this CA SHOULD be checked against CRL and/or OCSP, depending on contents of the extension.

The requiredNativeChecking limitation is identified by OID TBA.

requiredNativeChecking ::= SEQUENCE {
    RequiredCRLChecking BOOLEAN,
    RequiredOCSPChecking BOOLEAN
} applicationNameConstraints

This limitation are applied like Name Constraints limitation specified in RFC 5280.

This section implies 2 variants of checks:

The applicationNameConstraints limitation is specified according to RFC 5280, and reuses OID specified in RFC 5280.

      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }

      NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX) excludedIssueIntermediatory

When this limitation is present, the intermediate certificates issued by this CA MUST NOT be trusted.

The excludedIssueIntermediatory limitation is identified by OID TBA.

3. Verification of CLP

The verification of CLP SHOULD be performed by the application. The application should check whether the provided CLP matches the internal requirements and is correclty signed by the specified key.

4. Verification with CLP

In case of using CLP the checks enforced by CLP should be applied after the other checks.

The limitation provided by CLP MUST NOT extend the trustworthy of the checked certificate.

The limitations are applied after cryptographic validation of the certificate and during building its chain of trust. If the certificate or any of its ascendants in the chain of trust matches any record in the CLP, the limitations are applied from the ascendant to descendants. The issuedNotAfter and trustNotAfter limitations are applied to find out the actual validity periods for the any certificate in the chain of trust. If the CLP prescribes to have a particular extension(s) and the certificate does not have it, the certificate MUST NOT be trusted.

Application MAY use more than one CLPs (e.g. app-wide, set of system-wide, user-defined). When multiple CLPs are in use, the limitations are applied simultaneously.

In case when more than one chain of trust are valid for a certificate, if any of this chains is valid after applying the limitations, the certificate MUST be treated as valid.

5. ASN.1 notation


6. Security considerations

In case when an application uses CLP, it is recommended to specify the minimal date of issuing of the CLP document somewhere in code. It allows to avoid an attack of CLP rollback when the stale version of CLP is used.

It is recommended to distribute CLPs using the channels that are used for distribution of the applications themselves to avoid possible DoS consequences.

If application checks for fresh CLPs, it SHOULD check that nextUpdate field in a fresh one is newer than in the current one. The application MAY accept a CLP with nextUpdate in past. If an application is failing to get updates, then it can continue to run with what it has.

6.1. Unsigned CLP

In case of trusted environment signing CLP can be reluctant. If CLP is delivered via application bundle, it can be verified together with other application data. But it makes sense to separate trust to the source of the content from trust to the content itself. On the other hand it is not a problem to create a local CLP signed by a locally created key.

7. IANA considerations


8. Acknoledgements

Special thanks to Rich Salz, Igor Ustinov, Vasily Dolmatov, Stanislav Smyishlyaev, Patrik Fältström, Alexander Venedioukhin, Artem Chuprina, Viktor Dukhovni.

9. References

The current version of the document is available on GitHub

Author's Address

Dmitry Belyavskiy Technical Centre of Internet 8 Marta str., 1 bld. 12 Moscow, 127083 RU EMail:

Table of Contents