Realm Crossover for PKIX Certificates
draft-vanrein-cert-xover-00

Document Type Active Internet-Draft (individual)
Author Rick van Rein 
Last updated 2021-04-04
Stream (None)
Intended RFC status (None)
Formats pdf htmlized 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                                        R. Van Rein
Internet-Draft                                          InternetWide.org
Intended status: Informational                             April 4, 2021
Expires: October 6, 2021

                 Realm Crossover for PKIX Certificates
                      draft-vanrein-cert-xover-00

Abstract

   Certificates can express user attributes, but the semantics behind
   them, especially the validation policy, is not always clear.  This
   specification describes how domains can use their prerogative to
   define user identities for a recognised domain user.  This enables
   foreign realms to validate the identity of the domain user without
   with mere certificate logic.

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 October 6, 2021.

Copyright Notice

   Copyright (c) 2021 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

Van Rein                 Expires October 6, 2021                [Page 1]
Internet-Draft                 Cert Xover                     April 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Domain Registration Authorities . . . . . . . . . . . . . . .   3
   3.  Profile for Users of Domains  . . . . . . . . . . . . . . . .   3
     3.1.  Attributes  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Validation  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Trust . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Profile for Hosts under Domains . . . . . . . . . . . . . . .   8
     4.1.  Attributes  . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Validation  . . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Trust . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Profiles for Additional Attributes  . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Certificates bind a user identity to a public key, under approval of
   a Certificate Authority (CA).  Validation of certificates involves
   chasing a hierarchy of digital signatures until a root CA, and may
   additionally involve validation of intermediate CAs and/or root CA.

   DANE supports a mechanism to express validation constraints on
   certificates, including CA certificates, as part of DNS and under
   DNSSEC protection.  This means that the technical hierarchy of DNS is
   used to express trust in the certificate chain.  Depending on the
   purpose at hand, this may be interpreted as ultimate trust or part of
   a larger trust evaluation scheme.

   Clients usually identify themselves as users of a domain name, as
   domain names are the start of authority for online identity for
   individuals and organisations.  The user identity is a naming scope
   underneath the domain, so user identity assignment is the prerogative
   that comes with a domain name.  We express that by assuming that a
   domain has a Registration Authority (RA) to validate user requests
   for certificates.

   In many scenarios, the userid and domain name suffice as a form of
   identity.  In others, additional details matter and would need
   additional verification; for instance, when an organisation name or a
   personal name is mentioned.  We suggest two uses of DANE with client

Van Rein                 Expires October 6, 2021                [Page 2]
Internet-Draft                 Cert Xover                     April 2021

   certificates to support these two use cases.  The purpose is to
   support Realm Crossover for Certificates; that is, a setup where
   identity claims in one realm can be used in another realm, even when
   no prior relationships exist as a trust basis.

   Realm crossover for Certificates is part of a series of protocol
   enhancements, as overviewed in
   [I-D.vanrein-internetwide-realm-crossover].  Among the potential use
   cases are a global identity scheme for general communication and
   group participation, establishment of encryption keys, all with
   identity control under individually owned domains.

2.  Domain Registration Authorities

   In the PKIX model [RFC5280] the role of a Registration Authority (RA)
   is one to which the CA delegates some operational responsibilities.
   This specification introduces an RA underneath a domain, with access
   to the user database and can validate their identity.  In addition,
   it is setup to prove to the CA that it may issue certificates.

   The CA may be an external entity, or it may also be local to the
   domain.  If it is local, a combination of RA and CA operations is
   possible.  This would work for the Profile for Users of Domains
   Section 3, but it may be insufficient for the Profile for Additional
   Attributes Section 5.

   When the RA needs to prove to the CA that it acts on behalf of the
   domain, ACME [RFC8555] can be used.  ACME also contains a good chain
   of identifiers that assure that any proof is specific to an unloaded
   certificate request.  Being domain-centric, the domain RA could be
   granted the unique right to update the _acme-challenge label
   underneath the domain for the dns-01 challenge.  Having validated a
   request before considering the request, the domain RA is in a perfect
   position to know what to add and what not to add.

   Note that this centralised use of dns-01 does not preclude the use of
   ACME's more dispersed http-01 challenge mechanism; but the
   certificates issued in that way would still use the intended
   identity.  Where the use of other challenge methods is a concern, a
   domain could express this in centrally controlled DANE records for
   root or intermediate CA certificates that only use the dns-01
   challenge.

3.  Profile for Users of Domains

   In many online scenarios it suffices to know someone by their userid
   and domain name, such as "john@example.com".  Certificates holding an
   email address provide more semantics than mere identity, namely a

Van Rein                 Expires October 6, 2021                [Page 3]
Internet-Draft                 Cert Xover                     April 2021

   relation to a communication facility, and on the other end there are
   common name attributes, which may look like a host name but have no
   semantics of that kind attached.

   The most accurate solution would be to have a pure domain name and a
   user identity.  This information is the prerogative of the domain
   whose name is used, and structures exist to deliver trust in these
   elements without external complications.

3.1.  Attributes

   The "uid" or "userid" attribute [Section 2.39 of [RFC4519]] is
   intended for user identities, such as "john" in the example above.
   Its contents are a non-empty sequence of UTF-8 encoded UCS
   characters, which is almost the same as Unicode.  This is a good
   format for expressing user identities.

   The "dc" or "domainComponent" attribute [Section 2.4 of [RFC4519]] is
   intended for DNS labels, and a sequence of these attribute in
   immediate succession can be used to describe a domain name as it is
   represented in DNS.  Note that this notation allows A-labels for
   IDN2008 [RFC5890] but not the U-labels that should be rendered to
   users.

   This profile interprets attributes in the Subject of a Certificate
   [Section 4.1.2.6 of [RFC5280]].  The general order of the Subject is
   from low to high in the authoritative hierarchy.  This means that one
   "uid" value must precede two or more "dc" values.  All "dc" values
   must occur in immediate succession and in the same order as the DNS
   labels that they represent occur in the domain name.

   It is possible to have other attributes before the "uid", between the
   "uid" and first "dc" and after the last "dc" attribute.  This profile
   ignores such attributes, and assigns no trust to them.  It is quite
   possible that other profiles apply in addition to this one, in which
   case these extra attributes may be trusted from that perspective.  It
   is also possible that applications recognise the input as mere hints
   to construct a pleasant conversation, though without any legal or
   security implications.

   Examples of acceptable Subjects under this profile are:

   uid=john,dc=example,dc=com
   uid=john,dc=example,dc=com,associatedDomain=example.com
   uid=john,ou=Users,dc=example,dc=com
   cn=Johann+Johannson,uid=john,dc=example,dc=com
   uid=john,ou=Users,dc=example,dc=com,c=se

Van Rein                 Expires October 6, 2021                [Page 4]
Internet-Draft                 Cert Xover                     April 2021

   Examples of rejected Subjects under this profile are:

   dc=example,dc=com,uid=john
   dc=example,dc=com
   uid=john,dc=example
   uid=john,associatedDomain=example.com
   uid=john,uid=johann,dc=example,dc=com
   uid=john,dc=example,c=se,dc=com

3.2.  Validation

   Validation are the checks that parties run on a certificate request.
   This involves a few attributes:

   o  The request-originator is the client who submitted the certificate
      request.

   o  The request-signer is the CA that is destined to sign the
      certificate request.

   o  The request-key is the public key provided in the SubjectPublicKey
      field.

   o  The request-user is retrieved from the "uid" attribute in the
      Subject.  This takes the form of a UTF-8 string.

   o  The request-domain is constructed from the "dc" sequence, by
      concatenating them in their order of appearance in the Subject,
      separated by a dot.  The values in "dc" attributes may be A-labels
      when IDN2008 is applied; this means that the request-domain
      follows the customary DNS notation, but has no user-friendly form
      yet.

   The RA is sent a certificate request, and validates the following:

   o  The Subject attributes follow the description of Section 3.1.

   o  The Subject either does not fall under an LDAP service, or its
      object exists and represents the request-originator.

   o  The request-user is approved as a user under request-domain.

   o  The request-user falls under the control of the request-
      originator.

   o  The request-domain has a SOA record with DNSSEC protection.

   o  The request-key is controlled by the request-originator.

Van Rein                 Expires October 6, 2021                [Page 5]
Internet-Draft                 Cert Xover                     April 2021

   o  The request-signer is mentioned for Client DANE in the request-
      domain.

   o  The request-signer is trusted to validate the request-domain.

   o  The request-signer is trusted to retain the values of the "uid"
      and "dc" attributes.

   When this is assured, the RA forwards the certificate request to the
   request-signer, and expects to assert that this particular request
   originated from the request-domain.

   The request-signer is sent a certificate request, and validates the
   following:

   o  The Subject attributes follow the description of Section 3.1.

   o  The request-domain RA originated this particular request and
      approved it.

   o  The request-key is controlled by the request-originator.

   When this is assured, the request-signer removes any attributes that
   it disapproves of, but never "uid" and "dc", and turns the
   certificate request into a signed certificate.  It then returns that
   certificate to the request-domain's RA.

   The request-originator receives the signed certificate from the RA,
   and may validate the following:

   o  The Subject attributes follow the description of Section 3.1.

   o  The request-user, request-domain and request-key match the
      original request.

   o  The request-signer would normally be the one that was requested.

   The request-originator can now install the certificate and start
   using it towards a party that will hopefully trust its "uid" and "dc"
   attributes.

3.3.  Trust

   Trust in a certificate is the vital step of accepting the identity of
   an unknown party, in the case of this profile the identity of "uid"
   and "dc" attributes in the certificate Subject.  These attributes
   should adhere to the same constraints as for validation and on top of
   that, they must be confirmend under Client DANE.

Van Rein                 Expires October 6, 2021                [Page 6]
Internet-Draft                 Cert Xover                     April 2021

   User identities in DNS do not scale well.  They are often considered
   a privacy problem, and cache delays make user management slow and
   inconsistent.  Client DANE offers a better option, by mentioning a CA
   that signs for a domain's client certificates.

   The following steps are taken to evaluate trust in a certificate:

   o  The trust-user is retrieved from the "uid" attribute in the
      Subject.

   o  The trust-domain is constructed from the "dc" sequence, by
      concatenateing them in their order of appearance in the Subject,
      separated by a dot.

   o  For Client DANE, lookup TLSA records under TODO.[trust-domain]
      under the requirement that DNSSEC validates the TLSA records.

   o  Take note of any intermediate CA certificates in the TLSA records
      to validate the certificate.

   o  Validate the certificate under a root CA certificate from the TLSA
      records.

   After validation, the trust-user can be delivered as the certificate
   owner's user identity; the corresponding domain is formed like the
   trust-domain, except that A-labels are mapped to U-labels.

   TODO: role of intermediates: AND-or-OR requirements?

   Certificate attributes beyond "uid" and "dc" cannot be trusted; they
   may however provide hints for less formal uses, such as interfacing.
   When a Subject that ends in a sequence of "dc" attributes has a
   direct mapping to domain-bound LDAP service [RFC3088], so more
   structured information for the client may be found there.  These
   attributes are likely to be more dynamic than anything in the
   certificate; it may be searched, and incorporate access control to
   implement varying attribute visibility for varying requesters.

   Although it may be convenient to avoid lookups of DANE records, a
   well-known CA adds little value for this automated validation.  In
   fact, it adds an extra link in the chain of trust, in the form of a
   widely shared root key and delays in the validation.  If only these
   automation-friendly attributes are required, then it more secure to
   rely on DANE, possibly combined with DANE stapling and trust a
   domain's own CA under strict DNSSEC assurance.

Van Rein                 Expires October 6, 2021                [Page 7]
Internet-Draft                 Cert Xover                     April 2021

4.  Profile for Hosts under Domains

   Hosts are often used to run services for a domain name.  They are
   considered to either match the domain or one label below that.  A
   certificate may be applicable to multiple hosts.

4.1.  Attributes

   An old trick was to encode a host name in a "cn" or "commonName"
   attribute, but a modern and semantically more accurate approach is to
   use dNSName attributes in subjectAltName extensions [Section 4.2.1.6
   of [RFC5280]].  This habit has the additional benefit that it can
   represent multiple host names in one certificate.  The "cn" attribute
   is no longer needed, and need not be supported; we may however use
   "dc" attributes instead to represent the canonical host name.

   Hosts with a certificate tend to run services.  When they do, they
   publish those on a port for a particular service.  These values can
   be represented with attributes from the NIS scheme [RFC2307], namely
   "ipServicePort" (with values like "443") and "ipServiceProtocol"
   (with values like "tcp").  An additional "cn" (with values like
   "https") names the service on this protocol port, as standardised in
   IANA's Service Name and Transport Protocol Port Number Registry.
   Relative Distinguished Names combine these values in a SET, as in
   "ipServicePort=443+ipServiceProtocol=tcp+cn=https", which represents
   TCP port 443 for the HTTPS service.  Adding more ports and/or
   protocols creates more combinations, and each combination of port and
   protocol is assumed to exist and run the indicated service.  These
   RDNs can into the subjectAltName as a directoryName, alongside the
   dNSName values for virtual hostnames.

   Hosts never carry "uid" attributes, neither in their Subject nor in a
   subjectAltName value.

   TODO: Other attributes?

4.2.  Validation

   The following values are retrieved from the certificate request:

   o  The request-signer is the CA that is destined to sign the
      certificate request.

   o  The request-key is the public key provided in the SubjectPublicKey
      field.

   o  The request-host is constructed from the "dc" sequence, by
      concatenating them in their order of appearance in the Subject,

Van Rein                 Expires October 6, 2021                [Page 8]
Internet-Draft                 Cert Xover                     April 2021

      separated by a dot.  The values in "dc" attributes may be A-labels
      when IDN2008 is applied; this means that the request-domain
      follows the customary DNS notation, but has no user-friendly form
      yet.

   o  The request-domain is constructed like the request-host, but it
      does not use the first "dc" attribute in the Subject.

   o  The request-virtuals are the values in the subjectAltName
      extension tagged as dNSName.

   o  The request-ports are the values in the subjectAltName extension
      tagged as directoryName.

   The RA processes a certificate request by preparing for validation by
   the request-signer.  This may involve adding DANE records that will
   be required.  When done, the request is forwarded to the request-
   signer.

   TODO: Check that requester represents the host.  How?

   The request-signer processes a certificate request by validating the
   following:

   o  The request-domain must have a SOA record, secured with DNSSEC.

   o  The request-host must not have a SOA record, as confirmed with
      DNSSEC.

   o  Every element in the request-ports must be a single RDN, whose SET
      contains at least one "ipServicePort" element and at least one
      "ipServiceProtocol", one "cn" element and no other attribute
      types.  Within each such RDN, all possible combinations of an
      "ipServicePort" and an "ipServiceProtocol" are considered and
      subsequently combined with every element in request-virtuals.
      This leads to tuples of a protocol, port and DNS-name.

   o  Every tuple of a protocol, port and DNS-name is used to lookup a
      TLSA record.  One of the records found must represent the request-
      key as a DANE public key.  The "cn" element is not conidered,
      because the protocol is not being run.

4.3.  Trust

   When a certificate is found while accessing a service on a host, it
   can be used to build trust.  The information stored in DANE suffices
   to validate the relation of the connected service host with the
   domain, and in situation where this suffices there should be no

Van Rein                 Expires October 6, 2021                [Page 9]
Internet-Draft                 Cert Xover                     April 2021

   further need to validate the certificate based on an external CA.
   When depending on other attributes than "dNSName" and
   "ipServicePort+ipServiceProtocol+cn" this is usually desirable.

   Trust involves the following steps:

   o  Assure that the host name sent as SNI to the TLS service occurs in
      the certificate's subjectAltName as a dNSName value.

   o  Assure that the port and protocol appear in one directoryName, in
      one RDN, as "cn" with "ipServicePort" and "ipServiceProtocol",
      without regards for extra values for these attributes.

   o  Use DANE to lookup the host name, service protocol and service
      port and find a TLSA record that approves the TLS-sent
      certificate.

   Although it may be convenient to avoid lookups of DANE records, a
   well-known CA adds little value for this automated validation.  In
   fact, it adds an extra link in the chain of trust, in the form of a
   widely shared root key and delays in the validation.  If only these
   automation-friendly attributes are required, then it more secure to
   rely on DANE, possibly combined with DANE stapling and trust a
   domain's own CA under strict DNSSEC assurance.

   This profile is a little more specific than customary; the service
   protocol and service port are not normally verified, but it allowd
   for strong separation for service providers that may come together in
   one domain but be hosted by different parties who function at
   different security levels.  Their privacy levels or jurisdictions may
   also differ, which is a strong indication that they should not be
   permitted to overtake each other's traffic, just to be able to
   implement legislation.

5.  Profiles for Additional Attributes

   When the "uid" and "dc" fields provide insufficient trusted
   information, then an external authority may help to validate more
   information.  This is usually confirmed through an external CA.
   Examples include probing the user at an email addresses or URL.  More
   human attributes that may involve manual validation include the
   COSINE attributes [RFC4524].

   These additional attributes are not included in the Profile for Users
   of Domains Section 3 but they can be waved there due to the root CA
   which is validated through DNSSEC and DANE only.  Clearly, the
   validation path is of a technical nature and restrictions apply.

Van Rein                 Expires October 6, 2021               [Page 10]
Internet-Draft                 Cert Xover                     April 2021

   More classical root CAs tend to be well-known; they are listed and
   securely managed as part of an operating system or software
   distribution.  The additional validation that this brings implies
   trust in additional attributes.  Indeed, such CAs would not keep
   attributes that they are not comfortable with.

   A solution halfway is a federation of organisations, where the
   members hold certificates that are ultimately signed through the
   federation's CA.  This is another case of external CA and considered
   well-known, but only to the federation (and any parties that choose
   to also trust it).  This model is not as open because the CA is not
   installed as part of operating system or other software.  It is
   perfect for federation-internal security, but not outside that realm.

   TODO: Get concrete.

   TODO: Maybe add a new CA signature and extend the uid=,dc=,dc= form.

6.  Security Considerations

   CA must check the submitting RA to be responsible for the domain
   being claimed.

   CA must check dealing with an RA and not an arbitrary user under a
   domain.

7.  IANA Considerations

8.  Normative References

   [I-D.vanrein-internetwide-realm-crossover]
              Rein, R., "InternetWide Identities with Realm Crossover",
              draft-vanrein-internetwide-realm-crossover-00 (work in
              progress), September 2020.

   [RFC2307]  Howard, L., "An Approach for Using LDAP as a Network
              Information Service", RFC 2307, DOI 10.17487/RFC2307,
              March 1998, <https://www.rfc-editor.org/info/rfc2307>.

   [RFC3088]  Zeilenga, K., "OpenLDAP Root Service An experimental LDAP
              referral service", RFC 3088, DOI 10.17487/RFC3088, April
              2001, <https://www.rfc-editor.org/info/rfc3088>.

   [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
              (LDAP): Schema for User Applications", RFC 4519,
              DOI 10.17487/RFC4519, June 2006,
              <https://www.rfc-editor.org/info/rfc4519>.

Van Rein                 Expires October 6, 2021               [Page 11]
Internet-Draft                 Cert Xover                     April 2021

   [RFC4524]  Zeilenga, K., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
              DOI 10.17487/RFC4524, June 2006,
              <https://www.rfc-editor.org/info/rfc4524>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

Appendix A.  Acknowledgements

Author's Address

   Rick van Rein
   InternetWide.org
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl

Van Rein                 Expires October 6, 2021               [Page 12]