Certificate Limitation Policy
draft-belyavskiy-certificate-limitation-policy-04
The information below is for an old version of the document |
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2017-09-12
|
|
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 TCI
Intended status: Experimental September 11, 2017
Expires: March 15, 2018
Certificate Limitation Policy
draft-belyavskiy-certificate-limitation-policy-04
Abstract
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 https://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 March 15, 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
(https://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 March 15, 2018 [Page 1]
Internet-Draft Certificate Limitation Policy September 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 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 CLP
the certificate to verify the signature under the CLP file
minimal 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.
2. Certificate Limitations Profile
A proposed syntax and overall structure of CLP is very similar to the
one defined for CRLs [2].
Expires March 15, 2018 [Page 2]
Internet-Draft Certificate Limitation Policy September 2017
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertList ::= SEQUENCE {
version Version,
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
limitedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
Show full document text