Subject: [saag] A proposal: Certificate Limitation Policy

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 10 Apr 2017 15:30:41 +0300

Hello all,

I have a proposal inspired by the last "Google vs Symantec" case.

==============

Certificate Limitation Profile

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. So I suggest a
cryptographically protected format of description of such limitations.

The structure of suggested format is:

   -

   The date of issuance
   -

   The certificate with limited trust (serial + issuer), may be accompanied
   with optional fingerprint
   -

   The limitations applied to the certificate and/or all the descendants of
   it in the chain of trust.

Each limitation is specified by its own OID and applicability period. It
can have none/any/both of periodStart and periodEnd values.

The suggested list of limitations:

   -

   maxPeriodStart (do not trust the certs issued after)
   -

   maxPeriodEnd (do not trust the certs after)
   -

   validityPeriod (take minimal value from “native” validity period and
   specified in the limitation file)
   -

   ignoreX509Extensions (e.g. EV)
   -

   extraX509Extensions (treat all the certificates as having such an
   extension)
   -

   requiredX509extensions (do not trust the certificates )

The resulting file should be signed by the key with a special
keyUsage/extendedKeyUsage flag.
================
Is anybody interested in this proposal?

Thank you!

-- 
SY, Dmitry Belyavsky