idnits 2.17.1 draft-belyavskiy-certificate-limitation-policy-07.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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 115: '... } OPTIONAL,...' RFC 2119 keyword, line 117: '... } OPTIONAL,...' RFC 2119 keyword, line 178: '...certificate that MUST be ignored for t...' RFC 2119 keyword, line 181: '... list of X.509 extensions that MUST be...' RFC 2119 keyword, line 184: '...st of the CA-provided checks that MUST...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2018) is 1977 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 399 looks like a reference -- Missing reference section? '2' on line 402 looks like a reference -- Missing reference section? '3' on line 404 looks like a reference -- Missing reference section? '0' on line 290 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 November 25, 2018 5 Expires: May 29, 2019 7 Certificate Limitation Policy 8 draft-belyavskiy-certificate-limitation-policy-07 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 https://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 May 29, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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 (https://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 nextUpdate Time, 107 limitedCertificates SEQUENCE OF SEQUENCE { 108 userCertificate CertificateSerialNumber, 109 certificateIssuer Name, 110 limitationDate Time, 111 limitationPropagation Enum, 112 fingerprint SEQUENCE { 113 fingerprintAlgorithm AlgorithmIdentifier, 114 fingerprintValue OCTET STRING 115 } OPTIONAL, 116 limitations Limitations, 117 } OPTIONAL, 118 }; 120 Limitations ::= SEQUENCE SIZE (1..MAX) OF Limitation 122 Limitation ::= SEQUENCE { 123 limitID OBJECT IDENTIFIER, 124 LimitationValue OCTET STRING 125 -- contains the DER encoding of an ASN.1 value 126 -- corresponding to the limitation type 127 -- identified by limitID 128 } 130 The ASN.1 format of particular limitations is provided in the 131 corresponding sections. Anywhere below the Time in ASN.1 notation is 132 treated according to RFC 5280: 134 Time ::= CHOICE { 135 utcTime UTCTime, 136 generalTime GeneralizedTime } 138 2.1. CLP fields 140 CLP has general structure similar to CRLs. The upper-level fields 141 are: 143 TBSCertList - the sequence of individual certificates to be 144 limited; 146 signatureAlgorithm - the OID of the signature algorithm used for 147 signature; 149 signatureValue - the bit string representing signature of the 150 TBSCertList. 152 2.2. CLP signature 154 The key used for signing the CLP files should have a special Key 155 Usage value and/or an Extended Key Usage value. 157 2.3. CLP entry fields 159 Each entry in list contains the following fields: 161 The issuer of the certificate with limited trust. 163 The serial of the certificate with limited trust. 165 The fingerprint of the certificate with limited trust (optional). 167 and a subset of the following limitations: 169 issuedNotAfter - do not trust the certs issued after the specified 170 date 172 trustNotAfter - do not trust the certs after the specified date 174 validityPeriod, days - take minimal value from "native" validity 175 period and specified in the limitation file 177 ignoredX509Extensions - list of X.509 extensions of limited 178 certificate that MUST be ignored for the specified certificate 179 (e.g. EV-indicating extensions) 181 requiredX509extensions - list of X.509 extensions that MUST be 182 present in the certificate to be trusted. 184 requiredNativeChecking - list of the CA-provided checks that MUST 185 be applied 187 applicationNameConstraints - list of domains allowed to be issued 188 by this certificate 189 excludedIssueIntermediatory - disallow issuing of the 190 Intermediatory certificates 192 The limitations are identified by OIDs 194 2.3.1. Limitations 196 2.3.1.1. issuedNotAfter 198 When this limitation is present, any certificate matching the entry 199 and issued after the specified date MUST NOT be trusted 201 The issuedNotAfter limitation is identified by OID TBA. 203 issuedNotAfter ::= SEQUENCE { 204 IssuedNotAfter Time 205 } 207 2.3.1.2. trustNotAfter 209 When this limitation is present, any certificate matching the entry 210 MUST NOT be trusted after the specified date. 212 The trustNotAfter limitation is identified by OID TBA. 214 trustNotAfter ::= SEQUENCE { 215 TrustNotAfter Time 216 } 218 2.3.1.3. validityPeriod 220 When this limitation is present, no certificate matching the entry 221 should be treated as valid after specified period from its validFrom. 223 The validityPeriod is measured in days. 225 The validityPeriod limitation is identified by OID TBA. 227 validityPeriod ::= SEQUENCE { 228 Days INTEGER 229 } 231 2.3.1.4. ignoredX509Extensions 233 When this limitation is present, the extensions listed in this 234 element should be ignored for the matching certificate. 236 The ignoredX509Extensions limitation is identified by OID TBA. 238 ignoredX509Extensions :: = SEQUENCE SIZE (1..MAX) OF ExtenID 239 ExtenID :: = OBJECT IDENTIFIER 241 2.3.1.5. requiredX509extensions 243 When this limitation is present, the extensions listed in this 244 element should be present for the matching certificate. 246 The requiredX509extensions limitation is identified by OID TBA. 248 requiredX509extensions :: = SEQUENCE SIZE (1..MAX) OF ExtenID 249 ExtenID :: = OBJECT IDENTIFIER 251 2.3.1.6. requiredNativeChecking 253 When this limitation is present, it specifies that the certificates 254 issued by this CA SHOULD be checked against CRL and/or OCSP, 255 depending on contents of the extension. 257 The requiredNativeChecking limitation is identified by OID TBA. 259 requiredNativeChecking ::= SEQUENCE { 260 RequiredCRLChecking BOOLEAN, 261 RequiredOCSPChecking BOOLEAN 262 } 264 2.3.1.7. applicationNameConstraints 266 This limitation are applied like Name Constraints [3] limitation 267 specified in RFC 5280. 269 This section implies 2 variants of checks: 271 The list of names that are allowed for the CA to issue 272 certificates for 274 The list of names that are forbidden for the CA to issue 275 certificates for 277 The applicationNameConstraints limitation is specified according to 278 RFC 5280, 4.2.1.10 and reuses OID specified in RFC 5280. 280 id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } 282 NameConstraints ::= SEQUENCE { 283 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 284 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 286 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 288 GeneralSubtree ::= SEQUENCE { 289 base GeneralName, 290 minimum [0] BaseDistance DEFAULT 0, 291 maximum [1] BaseDistance OPTIONAL } 293 BaseDistance ::= INTEGER (0..MAX) 295 2.3.1.7.1. excludedIssueIntermediatory 297 When this limitation is present, the intermediate certificates issued 298 by this CA MUST NOT be trusted. 300 The excludedIssueIntermediatory limitation is identified by OID TBA. 302 3. Verification of CLP 304 The verification of CLP SHOULD be performed by the application. The 305 application should check whether the provided CLP matches the 306 internal requirements and is correclty signed by the specified key. 308 4. Verification with CLP 310 In case of using CLP the checks enforced by CLP should be applied 311 after the other checks. 313 The limitation provided by CLP MUST NOT extend the trustworthy of the 314 checked certificate. 316 The limitations are applied after cryptographic validation of the 317 certificate and during building its chain of trust. If the 318 certificate or any of its ascendants in the chain of trust matches 319 any record in the CLP, the limitations are applied from the ascendant 320 to descendants. The issuedNotAfter and trustNotAfter limitations are 321 applied to find out the actual validity periods for the any 322 certificate in the chain of trust. If the CLP prescribes to have a 323 particular extension(s) and the certificate does not have it, the 324 certificate MUST NOT be trusted. 326 Application MAY use more than one CLPs (e.g. app-wide, set of system- 327 wide, user-defined). When multiple CLPs are in use, the limitations 328 are applied simultaneously. 330 In case when more than one chain of trust are valid for a 331 certificate, if any of this chains is valid after applying the 332 limitations, the certificate MUST be treated as valid. 334 5. ASN.1 notation 336 TBD 338 6. Real-world considerations 340 6.1. Expected sources and consumers of CLPs 342 Public CLPs can be created and distributed by such parties as OS 343 vendors, browser vendors and other parties treated as worth trusting. 345 Usage of CLPs is reasonable for applications establishing TLS 346 connections with unpredictable sets of peers. The main examples of 347 such applications are web-browsers and MTAs. 349 6.2. Size limitation 351 To avoid uncontrolled growth of CLPs, the limitations are applied to 352 root and intermediate CA certificates. 354 7. Security considerations 356 In case when an application uses CLP, it is recommended to specify 357 the minimal date of issuing of the CLP document somewhere in code. 358 It allows to avoid an attack of CLP rollback when the stale version 359 of CLP is used. 361 It is recommended to distribute CLPs using the channels that are used 362 for distribution of the applications themselves to avoid possible DoS 363 consequences. 365 If application checks for fresh CLPs, it SHOULD check that nextUpdate 366 field in a fresh one is newer than in the current one. The 367 application MAY accept a CLP with nextUpdate in past. If an 368 application is failing to get updates, then it can continue to run 369 with what it has. 371 7.1. Unsigned CLP 373 In case of trusted environment signing CLP can be reluctant. If CLP 374 is delivered via application bundle, it can be verified together with 375 other application data. But it makes sense to separate trust to the 376 source of the content from trust to the content itself. On the other 377 hand it is not a problem to create a local CLP signed by a locally 378 created key. 380 8. IANA considerations 382 TBD 384 9. Acknoledgements 386 Special thanks to Rich Salz, Igor Ustinov, Vasily Dolmatov, Stanislav 387 Smyishlyaev, Patrik Faeltstroem, Alexander Venedioukhin, Artem 388 Chuprina, Viktor Dukhovni. 390 10. References 392 The current version of the document is available on GitHub 393 https://github.com/beldmit/clp 395 11. References 397 11.1. URIs 399 [1] https://groups.google.com/a/chromium.org/forum/#!msg/blink- 400 dev/eUAKwjihhBs/rpxMXjZHCQAJ 402 [2] https://tools.ietf.org/html/rfc5280#section-5 404 [3] https://tools.ietf.org/html/rfc5280#section-4.2.1.10 406 Author's Address 408 Dmitry Belyavskiy 409 Technical Centre of Internet 410 8 Marta str., 1 bld. 12 411 Moscow 127083 412 RU 414 Email: beldmit@gmail.com