idnits 2.17.1 draft-belyavskiy-certificate-limitation-policy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '... } OPTIONAL,...' RFC 2119 keyword, line 116: '... } OPTIONAL,...' RFC 2119 keyword, line 153: '...certificate that MUST be ignored for t...' RFC 2119 keyword, line 156: '... list of X.509 extensions that MUST be...' RFC 2119 keyword, line 169: '...the specified date MUST NOT be trusted...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 23, 2017) is 2462 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 262 looks like a reference -- Missing reference section? '2' on line 265 looks like a reference -- Missing reference section? '3' on line 267 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet-Draft TCI 4 Intended status: Experimental July 23, 2017 5 Expires: January 24, 2018 7 Certificate Limitation Policy 8 draft-belyavskiy-certificate-limitation-policy-03 10 Abstract 12 The document provides a specification of the application-level trust 13 model. Being provided at the application level, the limitations of 14 trust can be distributed separately using cryptographically protected 15 format instead of hardcoding the checks into the application itself. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 24, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 Binary trust model standardized as a set of trusted anchors and CRLs/ 52 OCSP services does not cover all corner cases in the modern crypto 53 world. There is a need in more differentiated limitations. Some of 54 them are suggested [1] by Google when it limits the usage of 55 Symantec's certificates. The CRL profile does not fit the purpose of 56 such limitations. The CRLs are issued by the same CAs that are 57 subject to be limited. 59 Currently the set of CAs trusted by OS or browsers can be used for 60 the validation purposes. In case when a large enough CA becomes 61 untrusted, it cannot be deleted from the storage of trusted CAs 62 because it may cause error of validation of many certificates. The 63 measures usually taken in such cases usually include application- 64 level limitation of certificates lifetimes, refusing to accept EV- 65 certificates in other way than DV, requirements to use Certificate 66 Transparency, etc. 68 This document suggests a cryptographically signed format dubbed 69 Certificate Limitation Profile (CLP) designed for description of such 70 limitations. This format can be used by applications that use 71 system-wide set of trust anchors for validating purposes or by 72 applications with own wide enough set of trusted anchors in case when 73 the trust anchor for the entity found misbehaving cannot be revoked. 75 Currently the only way to provide such limitations is hard coding 76 them in application itself. Using of CLPs does not allow to 77 completely avoid hard coding but allows to hard code only the minimal 78 set of rarely changing data: 80 the fact that application uses CLP 82 the certificate to verify the signature under the CLP file 84 minimal date of the CLP to be used for the current version of 85 application. 87 It will be possible to move the checks for the limitations to the 88 external cryptographical libraries, such as OpenSSL, instead of 89 checking them at the application level. 91 2. Certificate Limitations Profile 93 A proposed syntax and overall structure of CLP is very similar to the 94 one defined for CRLs [2]. 96 CertificateList ::= SEQUENCE { 97 tbsCertList TBSCertList, 98 signatureAlgorithm AlgorithmIdentifier, 99 signatureValue BIT STRING } 101 TBSCertList ::= SEQUENCE { 102 version Version, 103 signature AlgorithmIdentifier, 104 issuer Name, 105 thisUpdate Time, 106 limitedCertificates SEQUENCE OF SEQUENCE { 107 userCertificate CertificateSerialNumber, 108 certificateIssuer Name, 109 limitationDate Time, 110 limitationPropagation Enum, 111 fingerprint SEQUENCE { 112 fingerprintAlgorithm AlgorithmIdentifier, 113 fingerprintValue OCTET STRING 114 } OPTIONAL, 115 limitations SEQUENCE, 116 } OPTIONAL, 117 }; 119 2.1. CLP fields 121 TBD 123 2.2. CLP signature 125 The key used for signing the CLP files should have a special Key 126 Usage value and/or an Extended Key Usage value. 128 2.3. CLP entry fields 130 Each entry in list contains the following fields: 132 The issuer of the certificate with limited trust. 134 The serial of the certificate with limited trust. 136 The fingerprint of the certificate with limited trust (optional). 138 limitationPropagation. This field indicates whether limitations 139 are applied to the certificate itself, to all of its descendants 140 in the chain of trust, or both. 142 and a subset of the following limitations: 144 issuedNotAfter - do not trust the certs issued after the specified 145 date 147 trustNotAfter - do not trust the certs after the specified date 149 validityPeriod, days - take minimal value from "native" validity 150 period and specified in the limitation file 152 ignoredX509Extensions - list of X.509 extensions of limited 153 certificate that MUST be ignored for the specified certificate 154 (e.g. EV-indicating extensions) 156 requiredX509extensions - list of X.509 extensions that MUST be 157 present in the certificate to be trusted. 159 applicationNameConstraints - list of domains allowed to be issued 160 by this certificate 162 The limitations are identified by OIDs 164 2.3.1. Limitations 166 2.3.1.1. issuedNotAfter 168 When this limitation is present, any certificate matching the entry 169 and issued after the specified date MUST NOT be trusted 171 2.3.1.2. trustNotAfter 173 When this limitation is present, any certificate matching the entry 174 MUST NOT be trusted after the specified date. 176 2.3.1.3. validityPeriod 178 When this limitation is present, no certificate matching the entry 179 should be treated as valid after specified period from its validFrom. 181 2.3.1.4. ignoredX509Extensions 183 When this limitation is present, the extensions listed in this 184 element should be ignored for the matching certificate. 186 2.3.1.5. requiredX509extensions 188 When this limitation is present, the extensions listed in this 189 element should be present for the matching certificate. 191 2.3.1.6. applicationNameConstraints 193 This limitation are applied like Name Constraints [3] limitation 194 specified in RFC 5280. 196 3. Verification of CLP 198 The verification of CLP SHOULD be performed by the application. The 199 application should check whether the provided CLP matches the 200 internal requirements and is correclty signed by the specified key. 202 4. Verification with CLP 204 In case of using CLP the checks enforced by CLP should be applied 205 after the other checks. 207 The limitation provided by CLP MUST NOT extend the trustworthy of the 208 checked certificate. 210 The limitations are applied after cryptographic validation of the 211 certificate and during building its chain of trust. If the 212 certificate or any of its ascendants in the chain of trust matches 213 any record in the CLP, the limitations are applied from the ascendant 214 to descendants. The issuedNotAfter and trustNotAfter limitations are 215 applied to find out the actual validity periods for the any 216 certificate in the chain of trust. If the CLP prescribes to have a 217 particular extension(s) and the certificate does not have it, the 218 certificate MUST NOT be trusted. 220 Application MAY use more than one CLPs (e.g. app-wide, set of system- 221 wide, user-defined). When multiple CLPs are in use, the limitations 222 are applied simultaneously. 224 In case when more than one chain of trust are valid for a 225 certificate, if any of this chains is valid after applying the 226 limitations, the certificate MUST be treated as valid. 228 5. ASN.1 notation 230 TBD 232 6. Security considerations 234 In case when an application uses CLP, it is recommended to specify 235 the minimal date of issuing of the CLP document somewhere in code. 236 It allows to avoid an attack of CLP rollback when the stale version 237 of CLP is used. 239 It is recommended to distribute CLPs using the channels that are used 240 for distribution of the applications themselves to avoid possible DoS 241 consequences. 243 7. IANA considerations 245 TBD 247 8. Acknoledgements 249 Special thanks to Rich Salz, Igor Ustinov, Vasily Dolmatov, Stanislav 250 Smyishlyaev, Patrik Faeltstroem, Alexander Venedioukhin, Artem 251 Chuprina. 253 9. References 255 The current version of the document is available on GitHub 256 https://github.com/beldmit/clp 258 10. References 260 10.1. URIs 262 [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink- 263 dev/eUAKwjihhBs/rpxMXjZHCQAJ 265 [2] https://tools.ietf.org/html/rfc5280#section-5 267 [3] https://tools.ietf.org/html/rfc5280#section-4.2.1.10 269 Author's Address 271 Dmitry Belyavskiy 272 Technical Centre of Internet 274 Email: beldmit@gmail.com