Multi-Perspective Issuance Corroboration (MPIC) Service
draft-westerbaan-alldispatch-mpic-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Syed Suleman Ahmad , Bas Westerbaan , Henry Birge-Lee | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-westerbaan-alldispatch-mpic-00
Security Dispatch S. S. Ahmad
Internet-Draft B. Westerbaan
Intended status: Informational Cloudflare
Expires: 24 April 2025 H. Birge-Lee
Princeton University
21 October 2024
Multi-Perspective Issuance Corroboration (MPIC) Service
draft-westerbaan-alldispatch-mpic-00
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.
Ahmad, et al. Expires 24 April 2025 [Page 1]
Internet-Draft MPIC October 2024
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.
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. DCV . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. MPIC . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. MPIC service . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. API Structure . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. caa validation method . . . . . . . . . . . . . . . . . . 4
3.2. http-acme method . . . . . . . . . . . . . . . . . . . . 6
3.3. dns method . . . . . . . . . . . . . . . . . . . . . . . 9
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
Ahmad, et al. Expires 24 April 2025 [Page 2]
Internet-Draft MPIC October 2024
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
Ahmad, et al. Expires 24 April 2025 [Page 3]
Internet-Draft MPIC October 2024
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.
Ahmad, et al. Expires 24 April 2025 [Page 4]
Internet-Draft MPIC October 2024
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.
Ahmad, et al. Expires 24 April 2025 [Page 5]
Internet-Draft MPIC October 2024
{
"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.
Ahmad, et al. Expires 24 April 2025 [Page 6]
Internet-Draft MPIC October 2024
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.
Ahmad, et al. Expires 24 April 2025 [Page 7]
Internet-Draft MPIC October 2024
{
"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.", }
Ahmad, et al. Expires 24 April 2025 [Page 8]
Internet-Draft MPIC October 2024
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, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Ahmad, et al. Expires 24 April 2025 [Page 9]
Internet-Draft MPIC October 2024
[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/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, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Syed Suleman Ahmad
Cloudflare
Email: suleman@cloudflare.com
Bas Westerbaan
Cloudflare
Email: bas@cloudflare.com
Henry Birge-Lee
Princeton University
Email: birgelee@princeton.edu
Ahmad, et al. Expires 24 April 2025 [Page 10]