| < 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/ | ||||