idnits 2.17.1 draft-vanrein-cert-xover-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2021) is 1116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4519' is defined on line 522, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-vanrein-internetwide-realm-crossover-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft InternetWide.org 4 Intended status: Informational April 4, 2021 5 Expires: October 6, 2021 7 Realm Crossover for PKIX Certificates 8 draft-vanrein-cert-xover-00 10 Abstract 12 Certificates can express user attributes, but the semantics behind 13 them, especially the validation policy, is not always clear. This 14 specification describes how domains can use their prerogative to 15 define user identities for a recognised domain user. This enables 16 foreign realms to validate the identity of the domain user without 17 with mere certificate logic. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 6, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Domain Registration Authorities . . . . . . . . . . . . . . . 3 55 3. Profile for Users of Domains . . . . . . . . . . . . . . . . 3 56 3.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Profile for Hosts under Domains . . . . . . . . . . . . . . . 8 60 4.1. Attributes . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Profiles for Additional Attributes . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 Certificates bind a user identity to a public key, under approval of 73 a Certificate Authority (CA). Validation of certificates involves 74 chasing a hierarchy of digital signatures until a root CA, and may 75 additionally involve validation of intermediate CAs and/or root CA. 77 DANE supports a mechanism to express validation constraints on 78 certificates, including CA certificates, as part of DNS and under 79 DNSSEC protection. This means that the technical hierarchy of DNS is 80 used to express trust in the certificate chain. Depending on the 81 purpose at hand, this may be interpreted as ultimate trust or part of 82 a larger trust evaluation scheme. 84 Clients usually identify themselves as users of a domain name, as 85 domain names are the start of authority for online identity for 86 individuals and organisations. The user identity is a naming scope 87 underneath the domain, so user identity assignment is the prerogative 88 that comes with a domain name. We express that by assuming that a 89 domain has a Registration Authority (RA) to validate user requests 90 for certificates. 92 In many scenarios, the userid and domain name suffice as a form of 93 identity. In others, additional details matter and would need 94 additional verification; for instance, when an organisation name or a 95 personal name is mentioned. We suggest two uses of DANE with client 96 certificates to support these two use cases. The purpose is to 97 support Realm Crossover for Certificates; that is, a setup where 98 identity claims in one realm can be used in another realm, even when 99 no prior relationships exist as a trust basis. 101 Realm crossover for Certificates is part of a series of protocol 102 enhancements, as overviewed in 103 [I-D.vanrein-internetwide-realm-crossover]. Among the potential use 104 cases are a global identity scheme for general communication and 105 group participation, establishment of encryption keys, all with 106 identity control under individually owned domains. 108 2. Domain Registration Authorities 110 In the PKIX model [RFC5280] the role of a Registration Authority (RA) 111 is one to which the CA delegates some operational responsibilities. 112 This specification introduces an RA underneath a domain, with access 113 to the user database and can validate their identity. In addition, 114 it is setup to prove to the CA that it may issue certificates. 116 The CA may be an external entity, or it may also be local to the 117 domain. If it is local, a combination of RA and CA operations is 118 possible. This would work for the Profile for Users of Domains 119 Section 3, but it may be insufficient for the Profile for Additional 120 Attributes Section 5. 122 When the RA needs to prove to the CA that it acts on behalf of the 123 domain, ACME [RFC8555] can be used. ACME also contains a good chain 124 of identifiers that assure that any proof is specific to an unloaded 125 certificate request. Being domain-centric, the domain RA could be 126 granted the unique right to update the _acme-challenge label 127 underneath the domain for the dns-01 challenge. Having validated a 128 request before considering the request, the domain RA is in a perfect 129 position to know what to add and what not to add. 131 Note that this centralised use of dns-01 does not preclude the use of 132 ACME's more dispersed http-01 challenge mechanism; but the 133 certificates issued in that way would still use the intended 134 identity. Where the use of other challenge methods is a concern, a 135 domain could express this in centrally controlled DANE records for 136 root or intermediate CA certificates that only use the dns-01 137 challenge. 139 3. Profile for Users of Domains 141 In many online scenarios it suffices to know someone by their userid 142 and domain name, such as "john@example.com". Certificates holding an 143 email address provide more semantics than mere identity, namely a 144 relation to a communication facility, and on the other end there are 145 common name attributes, which may look like a host name but have no 146 semantics of that kind attached. 148 The most accurate solution would be to have a pure domain name and a 149 user identity. This information is the prerogative of the domain 150 whose name is used, and structures exist to deliver trust in these 151 elements without external complications. 153 3.1. Attributes 155 The "uid" or "userid" attribute [Section 2.39 of [RFC4519]] is 156 intended for user identities, such as "john" in the example above. 157 Its contents are a non-empty sequence of UTF-8 encoded UCS 158 characters, which is almost the same as Unicode. This is a good 159 format for expressing user identities. 161 The "dc" or "domainComponent" attribute [Section 2.4 of [RFC4519]] is 162 intended for DNS labels, and a sequence of these attribute in 163 immediate succession can be used to describe a domain name as it is 164 represented in DNS. Note that this notation allows A-labels for 165 IDN2008 [RFC5890] but not the U-labels that should be rendered to 166 users. 168 This profile interprets attributes in the Subject of a Certificate 169 [Section 4.1.2.6 of [RFC5280]]. The general order of the Subject is 170 from low to high in the authoritative hierarchy. This means that one 171 "uid" value must precede two or more "dc" values. All "dc" values 172 must occur in immediate succession and in the same order as the DNS 173 labels that they represent occur in the domain name. 175 It is possible to have other attributes before the "uid", between the 176 "uid" and first "dc" and after the last "dc" attribute. This profile 177 ignores such attributes, and assigns no trust to them. It is quite 178 possible that other profiles apply in addition to this one, in which 179 case these extra attributes may be trusted from that perspective. It 180 is also possible that applications recognise the input as mere hints 181 to construct a pleasant conversation, though without any legal or 182 security implications. 184 Examples of acceptable Subjects under this profile are: 186 uid=john,dc=example,dc=com 187 uid=john,dc=example,dc=com,associatedDomain=example.com 188 uid=john,ou=Users,dc=example,dc=com 189 cn=Johann+Johannson,uid=john,dc=example,dc=com 190 uid=john,ou=Users,dc=example,dc=com,c=se 191 Examples of rejected Subjects under this profile are: 193 dc=example,dc=com,uid=john 194 dc=example,dc=com 195 uid=john,dc=example 196 uid=john,associatedDomain=example.com 197 uid=john,uid=johann,dc=example,dc=com 198 uid=john,dc=example,c=se,dc=com 200 3.2. Validation 202 Validation are the checks that parties run on a certificate request. 203 This involves a few attributes: 205 o The request-originator is the client who submitted the certificate 206 request. 208 o The request-signer is the CA that is destined to sign the 209 certificate request. 211 o The request-key is the public key provided in the SubjectPublicKey 212 field. 214 o The request-user is retrieved from the "uid" attribute in the 215 Subject. This takes the form of a UTF-8 string. 217 o The request-domain is constructed from the "dc" sequence, by 218 concatenating them in their order of appearance in the Subject, 219 separated by a dot. The values in "dc" attributes may be A-labels 220 when IDN2008 is applied; this means that the request-domain 221 follows the customary DNS notation, but has no user-friendly form 222 yet. 224 The RA is sent a certificate request, and validates the following: 226 o The Subject attributes follow the description of Section 3.1. 228 o The Subject either does not fall under an LDAP service, or its 229 object exists and represents the request-originator. 231 o The request-user is approved as a user under request-domain. 233 o The request-user falls under the control of the request- 234 originator. 236 o The request-domain has a SOA record with DNSSEC protection. 238 o The request-key is controlled by the request-originator. 240 o The request-signer is mentioned for Client DANE in the request- 241 domain. 243 o The request-signer is trusted to validate the request-domain. 245 o The request-signer is trusted to retain the values of the "uid" 246 and "dc" attributes. 248 When this is assured, the RA forwards the certificate request to the 249 request-signer, and expects to assert that this particular request 250 originated from the request-domain. 252 The request-signer is sent a certificate request, and validates the 253 following: 255 o The Subject attributes follow the description of Section 3.1. 257 o The request-domain RA originated this particular request and 258 approved it. 260 o The request-key is controlled by the request-originator. 262 When this is assured, the request-signer removes any attributes that 263 it disapproves of, but never "uid" and "dc", and turns the 264 certificate request into a signed certificate. It then returns that 265 certificate to the request-domain's RA. 267 The request-originator receives the signed certificate from the RA, 268 and may validate the following: 270 o The Subject attributes follow the description of Section 3.1. 272 o The request-user, request-domain and request-key match the 273 original request. 275 o The request-signer would normally be the one that was requested. 277 The request-originator can now install the certificate and start 278 using it towards a party that will hopefully trust its "uid" and "dc" 279 attributes. 281 3.3. Trust 283 Trust in a certificate is the vital step of accepting the identity of 284 an unknown party, in the case of this profile the identity of "uid" 285 and "dc" attributes in the certificate Subject. These attributes 286 should adhere to the same constraints as for validation and on top of 287 that, they must be confirmend under Client DANE. 289 User identities in DNS do not scale well. They are often considered 290 a privacy problem, and cache delays make user management slow and 291 inconsistent. Client DANE offers a better option, by mentioning a CA 292 that signs for a domain's client certificates. 294 The following steps are taken to evaluate trust in a certificate: 296 o The trust-user is retrieved from the "uid" attribute in the 297 Subject. 299 o The trust-domain is constructed from the "dc" sequence, by 300 concatenateing them in their order of appearance in the Subject, 301 separated by a dot. 303 o For Client DANE, lookup TLSA records under TODO.[trust-domain] 304 under the requirement that DNSSEC validates the TLSA records. 306 o Take note of any intermediate CA certificates in the TLSA records 307 to validate the certificate. 309 o Validate the certificate under a root CA certificate from the TLSA 310 records. 312 After validation, the trust-user can be delivered as the certificate 313 owner's user identity; the corresponding domain is formed like the 314 trust-domain, except that A-labels are mapped to U-labels. 316 TODO: role of intermediates: AND-or-OR requirements? 318 Certificate attributes beyond "uid" and "dc" cannot be trusted; they 319 may however provide hints for less formal uses, such as interfacing. 320 When a Subject that ends in a sequence of "dc" attributes has a 321 direct mapping to domain-bound LDAP service [RFC3088], so more 322 structured information for the client may be found there. These 323 attributes are likely to be more dynamic than anything in the 324 certificate; it may be searched, and incorporate access control to 325 implement varying attribute visibility for varying requesters. 327 Although it may be convenient to avoid lookups of DANE records, a 328 well-known CA adds little value for this automated validation. In 329 fact, it adds an extra link in the chain of trust, in the form of a 330 widely shared root key and delays in the validation. If only these 331 automation-friendly attributes are required, then it more secure to 332 rely on DANE, possibly combined with DANE stapling and trust a 333 domain's own CA under strict DNSSEC assurance. 335 4. Profile for Hosts under Domains 337 Hosts are often used to run services for a domain name. They are 338 considered to either match the domain or one label below that. A 339 certificate may be applicable to multiple hosts. 341 4.1. Attributes 343 An old trick was to encode a host name in a "cn" or "commonName" 344 attribute, but a modern and semantically more accurate approach is to 345 use dNSName attributes in subjectAltName extensions [Section 4.2.1.6 346 of [RFC5280]]. This habit has the additional benefit that it can 347 represent multiple host names in one certificate. The "cn" attribute 348 is no longer needed, and need not be supported; we may however use 349 "dc" attributes instead to represent the canonical host name. 351 Hosts with a certificate tend to run services. When they do, they 352 publish those on a port for a particular service. These values can 353 be represented with attributes from the NIS scheme [RFC2307], namely 354 "ipServicePort" (with values like "443") and "ipServiceProtocol" 355 (with values like "tcp"). An additional "cn" (with values like 356 "https") names the service on this protocol port, as standardised in 357 IANA's Service Name and Transport Protocol Port Number Registry. 358 Relative Distinguished Names combine these values in a SET, as in 359 "ipServicePort=443+ipServiceProtocol=tcp+cn=https", which represents 360 TCP port 443 for the HTTPS service. Adding more ports and/or 361 protocols creates more combinations, and each combination of port and 362 protocol is assumed to exist and run the indicated service. These 363 RDNs can into the subjectAltName as a directoryName, alongside the 364 dNSName values for virtual hostnames. 366 Hosts never carry "uid" attributes, neither in their Subject nor in a 367 subjectAltName value. 369 TODO: Other attributes? 371 4.2. Validation 373 The following values are retrieved from the certificate request: 375 o The request-signer is the CA that is destined to sign the 376 certificate request. 378 o The request-key is the public key provided in the SubjectPublicKey 379 field. 381 o The request-host is constructed from the "dc" sequence, by 382 concatenating them in their order of appearance in the Subject, 383 separated by a dot. The values in "dc" attributes may be A-labels 384 when IDN2008 is applied; this means that the request-domain 385 follows the customary DNS notation, but has no user-friendly form 386 yet. 388 o The request-domain is constructed like the request-host, but it 389 does not use the first "dc" attribute in the Subject. 391 o The request-virtuals are the values in the subjectAltName 392 extension tagged as dNSName. 394 o The request-ports are the values in the subjectAltName extension 395 tagged as directoryName. 397 The RA processes a certificate request by preparing for validation by 398 the request-signer. This may involve adding DANE records that will 399 be required. When done, the request is forwarded to the request- 400 signer. 402 TODO: Check that requester represents the host. How? 404 The request-signer processes a certificate request by validating the 405 following: 407 o The request-domain must have a SOA record, secured with DNSSEC. 409 o The request-host must not have a SOA record, as confirmed with 410 DNSSEC. 412 o Every element in the request-ports must be a single RDN, whose SET 413 contains at least one "ipServicePort" element and at least one 414 "ipServiceProtocol", one "cn" element and no other attribute 415 types. Within each such RDN, all possible combinations of an 416 "ipServicePort" and an "ipServiceProtocol" are considered and 417 subsequently combined with every element in request-virtuals. 418 This leads to tuples of a protocol, port and DNS-name. 420 o Every tuple of a protocol, port and DNS-name is used to lookup a 421 TLSA record. One of the records found must represent the request- 422 key as a DANE public key. The "cn" element is not conidered, 423 because the protocol is not being run. 425 4.3. Trust 427 When a certificate is found while accessing a service on a host, it 428 can be used to build trust. The information stored in DANE suffices 429 to validate the relation of the connected service host with the 430 domain, and in situation where this suffices there should be no 431 further need to validate the certificate based on an external CA. 432 When depending on other attributes than "dNSName" and 433 "ipServicePort+ipServiceProtocol+cn" this is usually desirable. 435 Trust involves the following steps: 437 o Assure that the host name sent as SNI to the TLS service occurs in 438 the certificate's subjectAltName as a dNSName value. 440 o Assure that the port and protocol appear in one directoryName, in 441 one RDN, as "cn" with "ipServicePort" and "ipServiceProtocol", 442 without regards for extra values for these attributes. 444 o Use DANE to lookup the host name, service protocol and service 445 port and find a TLSA record that approves the TLS-sent 446 certificate. 448 Although it may be convenient to avoid lookups of DANE records, a 449 well-known CA adds little value for this automated validation. In 450 fact, it adds an extra link in the chain of trust, in the form of a 451 widely shared root key and delays in the validation. If only these 452 automation-friendly attributes are required, then it more secure to 453 rely on DANE, possibly combined with DANE stapling and trust a 454 domain's own CA under strict DNSSEC assurance. 456 This profile is a little more specific than customary; the service 457 protocol and service port are not normally verified, but it allowd 458 for strong separation for service providers that may come together in 459 one domain but be hosted by different parties who function at 460 different security levels. Their privacy levels or jurisdictions may 461 also differ, which is a strong indication that they should not be 462 permitted to overtake each other's traffic, just to be able to 463 implement legislation. 465 5. Profiles for Additional Attributes 467 When the "uid" and "dc" fields provide insufficient trusted 468 information, then an external authority may help to validate more 469 information. This is usually confirmed through an external CA. 470 Examples include probing the user at an email addresses or URL. More 471 human attributes that may involve manual validation include the 472 COSINE attributes [RFC4524]. 474 These additional attributes are not included in the Profile for Users 475 of Domains Section 3 but they can be waved there due to the root CA 476 which is validated through DNSSEC and DANE only. Clearly, the 477 validation path is of a technical nature and restrictions apply. 479 More classical root CAs tend to be well-known; they are listed and 480 securely managed as part of an operating system or software 481 distribution. The additional validation that this brings implies 482 trust in additional attributes. Indeed, such CAs would not keep 483 attributes that they are not comfortable with. 485 A solution halfway is a federation of organisations, where the 486 members hold certificates that are ultimately signed through the 487 federation's CA. This is another case of external CA and considered 488 well-known, but only to the federation (and any parties that choose 489 to also trust it). This model is not as open because the CA is not 490 installed as part of operating system or other software. It is 491 perfect for federation-internal security, but not outside that realm. 493 TODO: Get concrete. 495 TODO: Maybe add a new CA signature and extend the uid=,dc=,dc= form. 497 6. Security Considerations 499 CA must check the submitting RA to be responsible for the domain 500 being claimed. 502 CA must check dealing with an RA and not an arbitrary user under a 503 domain. 505 7. IANA Considerations 507 8. Normative References 509 [I-D.vanrein-internetwide-realm-crossover] 510 Rein, R., "InternetWide Identities with Realm Crossover", 511 draft-vanrein-internetwide-realm-crossover-00 (work in 512 progress), September 2020. 514 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 515 Information Service", RFC 2307, DOI 10.17487/RFC2307, 516 March 1998, . 518 [RFC3088] Zeilenga, K., "OpenLDAP Root Service An experimental LDAP 519 referral service", RFC 3088, DOI 10.17487/RFC3088, April 520 2001, . 522 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 523 (LDAP): Schema for User Applications", RFC 4519, 524 DOI 10.17487/RFC4519, June 2006, 525 . 527 [RFC4524] Zeilenga, K., Ed., "COSINE LDAP/X.500 Schema", RFC 4524, 528 DOI 10.17487/RFC4524, June 2006, 529 . 531 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 532 Housley, R., and W. Polk, "Internet X.509 Public Key 533 Infrastructure Certificate and Certificate Revocation List 534 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 535 . 537 [RFC5890] Klensin, J., "Internationalized Domain Names for 538 Applications (IDNA): Definitions and Document Framework", 539 RFC 5890, DOI 10.17487/RFC5890, August 2010, 540 . 542 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 543 Kasten, "Automatic Certificate Management Environment 544 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 545 . 547 Appendix A. Acknowledgements 549 Author's Address 551 Rick van Rein 552 InternetWide.org 553 Haarlebrink 5 554 Enschede, Overijssel 7544 WP 555 The Netherlands 557 Email: rick@openfortress.nl