Internet-Draft MPIC October 2024
Ahmad, et al. Expires 24 April 2025 [Page]
Workgroup:
Security Dispatch
Internet-Draft:
draft-westerbaan-alldispatch-mpic-00
Published:
Intended Status:
Informational
Expires:
Authors:
S. S. Ahmad
Cloudflare
B. Westerbaan
Cloudflare
H. Birge-Lee
Princeton University

Multi-Perspective Issuance Corroboration (MPIC) Service

Abstract

This memo defines an API for Multi-Perspective Issuance Corroboration (MPIC) services to facilitate domain control validation (DCV) from multiple network perspectives. MPIC enhances the security of publicly-trusted certificate issuance by mitigating the risk of localized, equally-specific BGP hijacking attacks that can undermine traditional DCV methods permitted by the CA/Browser Forum Baseline Requirements for TLS Server Certificates. This API enables Certification Authorities (CAs) to more reliably integrate with external MPIC providers, promoting a more robust and resilient Web PKI ecosystem. The API design prioritizes flexibility, scalability, and interoperability, allowing for diverse implementations and deployment models. This standardization effort is driven by the need to consistently address vulnerabilities in the domain validation process highlighted by recent research and real-world attacks, as reflected in Ballot SC-067 V3 of the CA/Browser Forum's Server Certificate Working Group.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://open-mpic.github.io/draft-mpic/draft-westerbaan-alldispatch-mpic.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-westerbaan-alldispatch-mpic/.

Discussion of this document takes place on the All Dispatch Working Group mailing list (mailto:alldispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/alldispatch/. Subscribe at https://www.ietf.org/mailman/listinfo/alldispatch/.

Source for this draft and an issue tracker can be found at https://github.com/open-mpic/draft-mpic.

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 24 April 2025.

Table of Contents

1. Introduction

1.1. DCV

Before issuing a certificate to a subscriber, certificate authorities are required to validate that the subscriber indeed controls the domains on the certificate. For this purpose certificate authorities use various methods of domain control validation (DCV), including but not limited to via HTTP, DNS, and ALPN.

1.2. MPIC

Several, but not all, CAs use the specific DCV methods of ACME [RFC8555]. Domain control validation is vulnerable to DNS and BGP hijacks. These can be partially mitigated by performing DCV from multiple network perspectives, which is dubbed "multiple perspective issuance corroboration" (MPIC). corroboration (MPIC) for domain control validation. Ballot SC-67 v3 of CA/B forum requires MPIC to be performed by all certification authorities (CAs) in the future.

1.3. MPIC service

Running MPIC requires maintaining a presence across the globe. For smaller CAs it may make sense to run a shared MPIC service or outsource it to a third party. This memo specifies a standardised API for such a usecase. Another usecase is for a CA to have a standby MPIC service in case its primary fails.

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. API Structure

The MPIC API implements a system for domain validation and CAA record checking using multiple perspectives across different regions.

An MPIC service can accept JSON requests over an arbitrary communication channel with an MPIC client. The MPIC service then produces MPIC responses which are sent back to the MPIC client over the communication channel. The communication channel may be synchronous (i.e., stall open on each MPIC request until an MPIC response is generated) or asynchronous (i.e., send a message to the MPIC service, close, and then receive a future message from the MPIC service containing a corresponding MPIC response). The MPIC service protocol does not provide any form of matching between MPIC requests and MPIC responses. A communication channel is responsible for ensuring that a client can match requests with corresponding responses. The communication channel MUST provide confidentiality and integrity as well as support for authentication of the MPIC service.

This document describes communication with an MPIC service using HTTPS POST as the communication channel. Alternate communication channels include gRPC, Apache Kafka, RabbitMQ, etc...

A MPIC service running over the HTTPS POST communication channel is identified by a HTTPS url. As a running example, say https://mpc.example.com/staging.

A client requests a MPIC validation from the service by sending a POST request to the resource /mpic/draft-00 below the service URL. In the running example https://mpc.example.com/staging/mpic/draft-00.

[[ The final version of the API will use /mpic/v1. Incompatible versions of the draft will bump the -00. ]]

The body of the HTTP POST is a JSON object that describs the MPIC request. The service will respond with a JSON object containing MPIC results.

There are three different MPIC validation methods, described below. The request object has a method field that allows to distinguish between each.

3.1. caa validation method

A caa requests asks the MPIC service to retrieve the relevant CAA DNS records for a given domain from multiple perspectives.

This method has the following specific fields.

  • domain (required, string): The domain to check the CAA records for.

An example request is given below.

POST /staging/mpic/draft-00
Host: mpc.example.com
Content-Type: application/json

{
 "method": "caa",
 "domain": "some.example.com"
}

If successful (described in TODO REF below), the response object contains a success field set to true, and an caa field, which itself is an object with two fields:

  • domain The domain on which the CAA records were found. This could be a parent domain of the requested domain.

  • records A list of base64 encoded CAA records.

An example of a response for a succesful validation.

{
 "success": true,
 "caa": {
  "domain": "example.com",
  "records": ["AAVpc3N1ZWxldHNlbmNyeXB0Lm9yZw=="]
 },
 "perspectives": {
  "jfk": {"success": true},
  "fra":  {"success": true},
  "lis": {"success": true}
 }
}

On failure, the response object will have the success field set to false, and an error field describing the error.

[[ TODO do we to define the possible errors, or at least assign some codes? ]]

An example of a response for an unsuccesful validation.

{
 "success": false,
  "perspectives": {
  "jfk": {"success": true},
  "fra":  {"success": true},
  "lis": {"success": false}
 },
 "error": "LIS saw record 'xyz' on example.com which was not present from perspective LIS"
}

[[ TODO How much information to return on error to help debug, and how structured should it be? I'd say it's good to be helpful, but it's bad to be structured as it's less readable. ]]

3.2. http-acme method

http-acme requests the MPIC server to perform ACME http-01 challenge validation [RFC8555] for the domain's HTTP server from each distributed perspectives.

Performs a GET from multiple perspectives, and checks whether the body matches expectation. Optionally, it allows performing an additional CAA record lookup for the domain.

The request JSON object has the following specific fields.

  • domain_or_ip (required, string): The domain name or IP address being verified.

  • token (required, string): The token value defined in [RFC8555] Section 8.3.

  • key_authorization (required, string): The Key Authorization defined in [RFC8555] Section 8.1.

  • caa_check (optional, boolean): Performs CAA validation at the same time for the domain as described above. Defaults to true unless domain_or_ip is an IP address.

POST /staging/mpic/draft-00
Host: mpc.example.com
Content-Type: application/json

{
 "method": "http-acme",
 "domain_or_ip": "some.example.com",
 "token": "base64_url_token",
 "key_authorization": "base64_url_token.base64url_Thumbprint_accountKey"
 "caa_check": false,
}

The MPIC server constructs a URL by populating the URL template [RFC6570], http://{domain_or_ip}/.well-known/acme-challenge/{token}, and verifies that the resulting URL is well-formed, before making a HTTP GET request to the URL from each vantage point. Each perspective SHOULD follow redirects when dereferencing the URL. The MPIC server verifies that the key_authorization value provided by the client matches with the body of the response received from each perspective.

If the above verifications succeeds, then the validation is successful. If the request fails, or the body does not pass these checks, then it has failed.

Along side, the MPIC server queries for the CAA records for the domain_or_ip if the caa_check request parameter is set to "true".

If either HTTP or CAA validation (when requested) fail, the response objects contains a top-level success field set to false, and contains an error field that describes the error.

If both succeed, the response object contains a top-level success field set to true.

The response also contains an object (located under the key perspectives) with keys that uniquiely identify the perspectives used in the reqest. Each perspective is associated with an object that contains success key pointing to a boolean value of true or false to indicate whether validation was successful at that perspective or not.

If a CAA check was requested, the response object will contain a top level caa field as described in Section 3.1.

An example of a response for a succesful validation with caa-check set to false.

{
 "success": true,
 "perspectives": {
  "jfk": {"success": true},
  "fra":  {"success": true},
  "lis": {"success": true}
 }
}

An example of a response for a succesful validation with caa-check set to true.

{
 "success": true,
 "perspectives": {
  "jfk": {"success": true},
  "fra":  {"success": true},
  "lis": {"success": true}
 }
 "caa": {
   "domain": "example.com",
   "records": ["AAVpc3N1ZWxldHNlbmNyeXB0Lm9yZw=="]
 }
}

An example of a response where the validation failed with caa_check set to true, and the caa method being successful.

{
 "success": false,
 "perspectives": {
  "jfk": {"success": true},
  "fra":  {"success": true},
  "lis": {"success": false}
 }
 "error": "HTTP found unexpected value at LIS perspective",
}

Similarly example of a response where caa_check set to true, and both methods fail.

{ "success": false, "perspectives": { "jfk": {"success": false}, "fra": {"success": true}, "lis": {"success": false} } "caa": { "domain": "example.com", "records": ["AAVpc3N1ZWxldHNlbmNyeXB0Lm9yZw=="] } "error": "HTTP found unexpected value at LIS perspective. CAA check failed at the JFK perspective.", }

3.3. dns method

Required request fields

  • domain

  • record-type

  • prefix

  • expected

Optional

  • caa Defaults to true.

Response is same as with http.

4. Operation

TODO describe operation of each.

5. Authentication

Describe usage of Authorization header.

6. Security Considerations

TODO Security

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8555]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.

8.2. Informative References

[RFC6570]
Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, , <https://www.rfc-editor.org/rfc/rfc6570>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Syed Suleman Ahmad
Cloudflare
Bas Westerbaan
Cloudflare
Henry Birge-Lee
Princeton University