< draft-aaron-acme-ari-01.txt   draft-aaron-acme-ari-02.txt >
ACME Working Group A. Gable ACME Working Group A. Gable
Internet-Draft Internet Security Research Group Internet-Draft Internet Security Research Group
Intended status: Standards Track 8 November 2021 Intended status: Standards Track 4 April 2022
Expires: 12 May 2022 Expires: 6 October 2022
Automated Certificate Management Environment (ACME) Renewal Information Automated Certificate Management Environment (ACME) Renewal Information
(ARI) Extension (ARI) Extension
draft-aaron-acme-ari-01 draft-aaron-acme-ari-02
Abstract Abstract
This document specifies how an ACME server may provide hints to ACME This document specifies how an ACME server may provide hints to ACME
clients as to when they should attempt to renew their certificates. clients as to when they should attempt to renew their certificates.
This allows servers to mitigate load spikes, and ensures clients do This allows servers to mitigate load spikes, and ensures clients do
not make false assumptions about appropriate certificate renewal not make false assumptions about appropriate certificate renewal
periods. periods.
Current Implementations Current Implementations
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 May 2022. This Internet-Draft will expire on 6 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Extensions to the ACME Protocol: The "directory" Resource . . 3 3. Extensions to the ACME Protocol: The "directory" Resource . . 3
4. Extensions to the ACME Protocol: The "renewalInfo" 4. Extensions to the ACME Protocol: The "renewalInfo"
Resource . . . . . . . . . . . . . . . . . . . . . . . . 3 Resource . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.1. Getting Renewal Information . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4.2. Updating Renewal Information . . . . . . . . . . . . . . 5
6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.2. ACME Resource Type . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.3. ACME Renewal Info Object Fields . . . . . . . . . . . . . 6 6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 6 6.2. ACME Resource Type . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7 6.3. ACME Renewal Info Object Fields . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Informative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Example Certificates . . . . . . . . . . . . . . . . 9
A.1. Example End-Entity Certificate . . . . . . . . . . . . . 9
Example CA Certificate . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Most ACME [RFC8555] clients today choose when to attempt to renew a Most ACME [RFC8555] clients today choose when to attempt to renew a
certificate in one of three ways. They may be configured to renew at certificate in one of three ways. They may be configured to renew at
a specific interval (e.g. via cron); they may parse the issued a specific interval (e.g. via cron); they may parse the issued
certificate to determine its expiration date and renew a specific certificate to determine its expiration date and renew a specific
amount of time before then; or they may parse the issued certificate amount of time before then; or they may parse the issued certificate
and renew when some percentage of its validity period has passed. and renew when some percentage of its validity period has passed.
The first two techniques create significant barriers against the The first two techniques create significant barriers against the
skipping to change at page 3, line 47 skipping to change at page 3, line 47
"meta": { "meta": {
"termsOfService": "https://example.com/acme/terms/2021-10-05", "termsOfService": "https://example.com/acme/terms/2021-10-05",
"website": "https://www.example.com/", "website": "https://www.example.com/",
"caaIdentities": ["example.com"], "caaIdentities": ["example.com"],
"externalAccountRequired": false "externalAccountRequired": false
} }
} }
4. Extensions to the ACME Protocol: The "renewalInfo" Resource 4. Extensions to the ACME Protocol: The "renewalInfo" Resource
We define a new resource type, the "renewalInfo" resource, as part of The "renewalInfo" resource is a new resource type introduced to ACME
the ACME protocol. To request the suggested renewal information for protocol. This new resource both allows clients to query the server
a certificate, the client sends a GET request to a path under the for suggestions on when they should renew certificates, and allows
server's renewalInfo URL. clients to inform the server when they have completed renewal (or
otherwise replaced the certificate to their satisfaction).
The full request URL is computed by concatenating the renewalInfo URL 4.1. Getting Renewal Information
from the server's directory with the following case-insensitive hex-
encoded (see [RFC4648], Section [RFC4648]) elements, separated by
forward slashes:
* the SHA-1 hash of the issuer's public key (often included in the To request the suggested renewal information for a certificate, the
certificate as the Authority Key Identifier, see [RFC5280], client sends a GET request to a path under the server's renewalInfo
Section [RFC5280]), URL.
* the SHA-1 hash of the issuer's Distinguished Name, see [RFC5280], The full request URL is computed by concatenating the renewalInfo URL
Section [RFC5280], and from the server's directory with a forward slash and the base64url-
encoded [RFC4648] bytes of a DER-encoded CertID ASN.1 sequence
[RFC6960]. Trailing '=' characters MUST be stripped.
* the certificate serial number. For example, to request renewal information for the end-entity
certificate given in Appendix A.1, issued by the CA certificate given
in Appendix A.2, using SHA256, the client would make the following
request (the path has been split onto multiple lines for
readability):
These are the same components that make up the CertID sequence of an GET https://example.com/acme/renewal-info/
OCSPRequest [RFC6960], Section [RFC6960], with the caveat that the MFswCwYJYIZIAWUDBAIBBCCeWLRusNLb--vmWOkxm34qDjTMWkc
hash algorithm is restricted to SHA-1, in line with [RFC5019]. 3utIhOMoMwKDqbgQg2iiKWySZrD-6c88HMZ6vhIHZPamChLlzGH
eZ7pTS8jYCCD6jRWhlRB8c
GET https://example.com/acme/renewal-info The ACME Server MAY restrict the hash algorithms which it accepts
/254581685026383D3B2D2CBECD6AD9B63DB36663 (for example, only allowing SHA256 to limit the number of potential
/06FE0BABD8E6746EFCC4730285F7A9487ED1344F cache keys); if it receives a request whose embedded
/BCDF4596B6BDC523 signatureAlgorithm field contains an unacceptable OID, it SHOULD
respond with HTTP status code 400 (Bad Request).
The structure of an ACME renewalInfo resource is as follows: The structure of an ACME renewalInfo resource is as follows:
suggestedWindow (object, required): A JSON object with two keys, suggestedWindow (object, required): A JSON object with two keys,
"start" and "end", whose values are timestamps, encoded in the format "start" and "end", whose values are timestamps, encoded in the format
specified in [RFC3339], which bound the window of time in which the specified in [RFC3339], which bound the window of time in which the
CA recommends renewing the certificate. CA recommends renewing the certificate.
explanationURL (string, optional): A URL pointing to a page which may
explain why the suggested renewal window is what it is. For example,
it may be a page explaining the CA's dynamic load-balancing strategy,
or a page documenting which certificates are affected by a mass
revocation event. Conforming clients SHOULD provide this URL to
their operator, if present.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Retry-After: "21600" Retry-After: 21600
{ {
"suggestedWindow": { "suggestedWindow": {
"start": "2021-01-03T00:00:00Z", "start": "2021-01-03T00:00:00Z",
"end": "2021-01-07T00:00:00Z" "end": "2021-01-07T00:00:00Z"
} },
"explanationURL": "https://example.com/docs/example-mass-reissuance-event"
} }
The server SHOULD include a Retry-After header indicating the polling The server SHOULD include a Retry-After header indicating the polling
interval that the ACME server recommends. Conforming clients SHOULD interval that the ACME server recommends. Conforming clients SHOULD
query the renewalInfo URL again after the Retry-After period has query the renewalInfo URL again after the Retry-After period has
passed, as the server may provide a different suggestedWindow. passed, as the server may provide a different suggestedWindow.
Conforming clients MUST select a uniform random time within the Conforming clients MUST select a uniform random time within the
suggested window to attempt to renew the certificate. If the suggested window to attempt to renew the certificate. If the
selected time is in the past, the client SHOULD attempt renewal selected time is in the past, the client SHOULD attempt renewal
skipping to change at page 5, line 26 skipping to change at page 5, line 43
frequency doesn't lead to retrying failures without proper backoff. frequency doesn't lead to retrying failures without proper backoff.
Typical information stored should include: number of failures for a Typical information stored should include: number of failures for a
given order (defined by the set of names on the order), and time of given order (defined by the set of names on the order), and time of
the most recent failure. the most recent failure.
If the client receives no response or a malformed response (e.g. an If the client receives no response or a malformed response (e.g. an
end timestamp which precedes the start timestamp), it SHOULD make its end timestamp which precedes the start timestamp), it SHOULD make its
own determination of when to renew the certificate, and MAY retry the own determination of when to renew the certificate, and MAY retry the
renewalInfo request with appropriate exponential backoff behavior. renewalInfo request with appropriate exponential backoff behavior.
4.2. Updating Renewal Information
To update the renewal status of a certificate, the client sends a
POST request to the server's renewalInfo URL.
The body of the POST is a JWS object which is authenticated to an
account as defined in [RFC8555], Section 6.2, and whose JSON payload
has the following structure:
certID (required, string): The CertID of the certificate whose
renewal information should be updated, in the base64url-encoded
version of the DER format with trailing "=" stripped. Note: this is
identical to the final path component constructed for GET requests
above.
replaced (required, boolean): Whether or not the client considers the
certificate to have been replaced. A certificate is considered
replaced when its revocation would not disrupt any ongoing services,
for instance because it has been renewed and the new certificate is
in use, or because it is no longer in use. Clients SHOULD NOT send a
request where this value is false.
POST /acme/renewal-info HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/renewal-info"
}),
"payload": base64url({
"certID": "MFswCwYJ...RWhlRB8c",
"replaced": true
}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
The server MUST verify that the request is signed by the account key
of the Subscriber to which the certificate was originally issued. If
the server accepts the request and the update succeeds, it responds
with HTTP status code 200 (OK). If the update is rejected or fails,
for example because the certificate has already been marked as
replaced, the server returns an error.
The server might use this renewal update to inform a number of
processes, such as: not sending renewal reminder notifications for
certificates that have been marked as replaced; sending empty or
error responses to subsequent requests for the certificate's renewal
information; or confidently revoking certificates subject to a mass
revocation without fear of disrupting the Subscriber's operations.
5. Security Considerations 5. Security Considerations
The extensions to the ACME protocol described in this document build The extensions to the ACME protocol described in this document build
upon the Security Considerations and threat model defined in upon the Security Considerations and threat model defined in
[RFC8555], Section [RFC8555]. [RFC8555], Section Section 10.1.
This document specifies that renewalInfo resources MUST be exposed This document specifies that renewalInfo resources MUST be exposed
and accessed via unauthenticated GET requests, a departure from and accessed via unauthenticated GET requests, a departure from
RFC8555's requirement that clients must send POST-as-GET requests to RFC8555's requirement that clients must send POST-as-GET requests to
fetch resources from the server. This is because the information fetch resources from the server. This is because the information
contained in renewalInfo resources is not considered confidential, contained in renewalInfo resources is not considered confidential,
and because allowing renewalInfo to be easily cached is advantageous and because allowing renewalInfo to be easily cached is advantageous
to shed load from clients which do not respect the Retry-After to shed load from clients which do not respect the Retry-After
header. header.
skipping to change at page 6, line 11 skipping to change at page 7, line 37
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry, IANA has created the new "ACME Renewal Info Protocol" registry, IANA has created the new "ACME Renewal Info
Object Fields" registry (Section 6.4). Object Fields" registry (Section 6.4).
6.2. ACME Resource Type 6.2. ACME Resource Type
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry, the following entry has been added to the "ACME Protocol" registry, the following entry has been added to the "ACME
Resource Types" registry. Resource Types" registry.
+=============+=====================+============+ +=============+=====================+===============+
| Field Name | Resource Type | Reference | | Field Name | Resource Type | Reference |
+=============+=====================+============+ +=============+=====================+===============+
| renewalInfo | Renewal Info object | This draft | | renewalInfo | Renewal Info object | This document |
+-------------+---------------------+------------+ +-------------+---------------------+---------------+
Table 2 Table 2
6.3. ACME Renewal Info Object Fields 6.3. ACME Renewal Info Object Fields
The "ACME Renewal Info Object Fields" registry lists field names that The "ACME Renewal Info Object Fields" registry lists field names that
are defined for use in ACME renewal info objects. are defined for use in ACME renewal info objects.
Template: Template:
* Field name: The string to be used as a field name in the JSON * Field name: The string to be used as a field name in the JSON
object object
* Field type: The type of value to be provided, e.g., string, * Field type: The type of value to be provided, e.g., string,
boolean, array of string boolean, array of string
* Reference: Where this field is defined * Reference: Where this field is defined
Initial contents: Initial contents:
+=================+============+============+ +=================+============+===============+
| Field Name | Field type | Reference | | Field Name | Field type | Reference |
+=================+============+============+ +=================+============+===============+
| suggestedWindow | object | This draft | | suggestedWindow | object | This document |
+-----------------+------------+------------+ +-----------------+------------+---------------+
Table 3 Table 3
7. Normative References 7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Certificate Status Protocol (OCSP) Profile for High-Volume Galperin, S., and C. Adams, "X.509 Internet Public Key
Environments", RFC 5019, DOI 10.17487/RFC5019, September Infrastructure Online Certificate Status Protocol - OCSP",
2007, <https://www.rfc-editor.org/info/rfc5019>. RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
8. Informative References 8. Informative References
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [boulder] Internet Security Research Group, "Boulder", 2022,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[boulder] Internet Security Research Group, "Boulder", 2021,
<https://github.com/letsencrypt/boulder>. <https://github.com/letsencrypt/boulder>.
[lestaging] [lestaging]
Internet Security Research Group, "Let's Encrypt Staging Internet Security Research Group, "Let's Encrypt Staging
Environment", 2021, Environment", 2022,
<https://acme-staging-v02.api.letsencrypt.org/directory>. <https://acme-staging-v02.api.letsencrypt.org/directory>.
Appendix A. Example Certificates
A.1. Example End-Entity Certificate
-----BEGIN CERTIFICATE-----
MIIDMDCCAhigAwIBAgIIPqNFaGVEHxwwDQYJKoZIhvcNAQELBQAwIDEeMBwGA1UE
AxMVbWluaWNhIHJvb3QgY2EgM2ExMzU2MB4XDTIyMDMxNzE3NTEwOVoXDTI0MDQx
NjE3NTEwOVowFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCgm9K/c+il2Pf0f8qhgxn9SKqXq88cOm9ov9AVRbPA
OWAAewqX2yUAwI4LZBGEgzGzTATkiXfoJ3cN3k39cH6tBbb3iSPuEn7OZpIk9D+e
3Q9/hX+N/jlWkaTB/FNA+7aE5IVWhmdczYilXa10V9r+RcvACJt0gsipBZVJ4jfJ
HnWJJGRZzzxqG/xkQmpXxZO7nOPFc8SxYKWdfcgp+rjR2ogYhSz7BfKoVakGPbpX
vZOuT9z4kkHra/WjwlkQhtHoTXdAxH3qC2UjMzO57Tx+otj0CxAv9O7CTJXISywB
vEVcmTSZkHS3eZtvvIwPx7I30ITRkYk/tLl1MbyB3SiZAgMBAAGjeDB2MA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBQ4zzDRUaXHVKqlSTWkULGU4zGZpTAWBgNVHREE
DzANggtleGFtcGxlLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAx0aYvmCk7JYGNEXe
+hrOfKawkHYzWvA92cI/Oi6h+oSdHZ2UKzwFNf37cVKZ37FCrrv5pFP/xhhHvrNV
EnOx4IaF7OrnaTu5miZiUWuvRQP7ZGmGNFYbLTEF6/dj+WqyYdVaWzxRqHFu1ptC
TXysJCeyiGnR+KOOjOOQ9ZlO5JUK3OE4hagPLfaIpDDy6RXQt3ss0iNLuB1+IOtp
1URpvffLZQ8xPsEgOZyPWOcabTwJrtqBwily+lwPFn2mChUx846LwQfxtsXU/lJg
HX2RteNJx7YYNeX3Uf960mgo5an6vE8QNAsIoNHYrGyEmXDhTRe9mCHyiW2S7fZq
o9q12g==
-----END CERTIFICATE-----
Example CA Certificate
-----BEGIN CERTIFICATE-----
MIIDSzCCAjOgAwIBAgIIOhNWtJ7Igr0wDQYJKoZIhvcNAQELBQAwIDEeMBwGA1UE
AxMVbWluaWNhIHJvb3QgY2EgM2ExMzU2MCAXDTIyMDMxNzE3NTEwOVoYDzIxMjIw
MzE3MTc1MTA5WjAgMR4wHAYDVQQDExVtaW5pY2Egcm9vdCBjYSAzYTEzNTYwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3P6cxcCZ7FQOQrYuigReSa8T
IOPNKmlmX9OrTkPwjThiMNEETYKO1ea99yXPK36LUHC6OLmZ9jVQW2Ny1qwQCOy6
TrquhnwKgtkBMDAZBLySSEXYdKL3r0jA4sflW130/OLwhstU/yv0J8+pj7eSVOR3
zJBnYd1AqnXHRSwQm299KXgqema7uwsa8cgjrXsBzAhrwrvYlVhpWFSv3lQRDFQg
c5Z/ZDV9i26qiaJsCCmdisJZWN7N2luUgxdRqzZ4Cr2Xoilg3T+hkb2y/d6ttsPA
kaSA+pq3q6Qa7/qfGdT5WuUkcHpvKNRWqnwT9rCYlmG00r3hGgc42D/z1VvfAgMB
AAGjgYYwgYMwDgYDVR0PAQH/BAQDAgKEMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQ4zzDRUaXHVKql
STWkULGU4zGZpTAfBgNVHSMEGDAWgBQ4zzDRUaXHVKqlSTWkULGU4zGZpTANBgkq
hkiG9w0BAQsFAAOCAQEArbDHhEjGedjb/YjU80aFTPWOMRjgyfQaPPgyxwX6Dsid
1i2H1x4ud4ntz3sTZZxdQIrOqtlIWTWVCjpStwGxaC+38SdreiTTwy/nikXGa/6W
ZyQRppR3agh/pl5LHVO6GsJz3YHa7wQhEhj3xsRwa9VrRXgHbLGbPOFVRTHPjaPg
Gtsv2PN3f67DsPHF47ASqyOIRpLZPQmZIw6D3isJwfl+8CzvlB1veO0Q3uh08IJc
fspYQXvFBzYa64uKxNAJMi4Pby8cf4r36Wnb7cL4ho3fOHgAltxdW8jgibRzqZpQ
QKyxn2jX7kxeUDt0hFDJE8lOrhP73m66eBNzxe//FQ==
-----END CERTIFICATE-----
Acknowledgments Acknowledgments
TODO acknowledge. TODO acknowledge.
Author's Address Author's Address
A. Gable A. Gable
Internet Security Research Group Internet Security Research Group
Email: aaron@letsencrypt.org Email: aaron@letsencrypt.org
 End of changes. 27 change blocks. 
72 lines changed or deleted 180 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/