| spasm | |
| Internet-Draft | June 20, 2017 |
| Intended status: Experimental | |
| Expires: December 22, 2017 |
Certificate Limitation Policy
draft-belyavskiy-certificate-limitation-policy-00
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.
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 December 22, 2017.
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.
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 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, refuse to accept EV-certificates in other way than DV, requirements of usage Certificate Transparency, etc.
This document suggests a cryptographically protected format of 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 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, such as the certificate to verify the signature and minimal date of issuance (see below).
A proposed syntax and overall structure of CLP is very similar to the one defined for CRLs. TBD.
TBD
TBD
The key used for signing the CLP files should have a special Key Usage bit and/or an Extended Key Usage value.
Each entry in list contains the following fields:
and a subset of the following limitations:
The limitations are identified by OIDs
When this limitation is present, no certificate matching the entry and issued after the specified date should not be trusted
When this limitation is present, no certificate matching the entry should be trusted after the specified date.
When this limitation is present, no certificate matching the entry should be treated as valid after specified period from its validFrom.
When this limitation is present, the extensions listed in this element should be ignored for the matching certificate.
When this limitation is present, the extensions listed in this element should be present for the matching certificate.
TBD
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.
The current version of the document is available on GitHub https://github.com/beldmit/clp