Certificate Limitation PolicyTechnical Centre of Internetbeldmit@gmail.com
sec
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.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:
the fact that application uses CLPthe certificate to verify the signature under the CLP fileminimal date of the CLP to be used for the current version of application.
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.A proposed syntax and overall structure of CLP is very similar to the one
defined for
CRLs.
TBDThe key used for signing the CLP files should have a special Key Usage value and/or
an Extended Key Usage value.Each entry in list contains the following fields:
The issuer of the certificate with limited trust.The serial of the certificate with limited trust.The fingerprint of the certificate with limited trust (optional).limitationPropagation. This field indicates whether limitations are applied to the certificate
itself, to all of its descendants in the chain of trust, or both.
and a subset of the following limitations:
issuedNotAfter - do not trust the certs issued after the specified datetrustNotAfter - do not trust the certs after the specified datevalidityPeriod, days - take minimal value from "native" validity period and specified in the limitation fileignoredX509Extensions - list of X.509 extensions of limited certificate that MUST be ignored for the specified certificate (e.g. EV-indicating extensions)requiredX509extensions - list of X.509 extensions that MUST be present in the certificate to be trusted.applicationNameConstraints - list of domains allowed to be issued by this certificateThe limitations are identified by OIDsWhen this limitation is present, any certificate matching the entry and
issued after the specified date MUST NOT be trustedWhen this limitation is present, any certificate matching the entry MUST NOT
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.This limitation are applied like Name
Constraints limitation specified in RFC 5280.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.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.TBDIn 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.TBDSpecial thanks to Rich Salz, Igor Ustinov, Vasily Dolmatov, Stanislav
Smyishlyaev, Patrik Fältström, Alexander Venedioukhin, Artem Chuprina. The current version of the document is available on GitHub
https://github.com/beldmit/clp