Automatic Certificate Management Environment (ACME)Mozillarlb@ipv.sxEFFpde@eff.orgEFFschoen@eff.orgUniversity of Michiganjhalderm@eecs.umich.eduUniversity of Michiganjdkasten@umich.eduCertificates in the Web’s X.509 PKI (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certificate authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.Certificates in the Web PKI are most commonly used to authenticate domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate.Existing Web PKI certificate authorities tend to run on a set of ad hoc protocols for certificate issuance and identity verification. A typical user experience is something like:Generate a PKCS#10 Certificate Signing Request (CSR).Cut-and-paste the CSR into a CA web page.Prove ownership of the domain by one of the following methods:
Put a CA-provided challenge at a specific place on the web server.Put a CA-provided challenge at a DNS location corresponding to the target domain.Receive CA challenge at a (hopefully) administrator-controlled e-mail address corresponding to the domain and then respond to it on the CA’s web page.Download the issued certificate and install it on their Web Server.With the exception of the CSR itself and the certificates that are issued, these are all completely ad hoc procedures and are accomplished by getting the human user to follow interactive natural-language instructions from the CA rather than by machine-implemented published protocols. In many cases, the instructions are difficult to follow and cause significant confusion. Informal usability tests by the authors indicate that webmasters often need 1-3 hours to obtain and install a certificate for a domain. Even in the best case, the lack of published, standardized mechanisms presents an obstacle to the wide deployment of HTTPS and other PKIX-dependent systems because it inhibits mechanization of tasks related to certificate issuance, deployment, and revocation.This document describes an extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructural software to obtain certificates without user interaction. Use of this protocol should radically simplify the deployment of HTTPS and the practicality of PKIX authentication for other TLS based protocols.The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS ). In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is intended to verify that the server actually speaks for the domain.Different types of certificates reflect different kinds of CA verification of information about the certificate subject. “Domain Validation” (DV) certificates are by far the most common type. For DV validation, the CA merely verifies that the requester has effective control of the web server and/or DNS server for the domain, but does not explicitly attempt to verify their real-world identity. (This is as opposed to “Organization Validation” (OV) and “Extended Validation” (EV) certificates, where the process is intended to also verify the real-world identity of the requester.)DV certificate validation commonly checks claims about properties related to control of a domain name – properties that can be observed by the issuing authority in an interactive process that can be conducted purely online. That means that under typical circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention.When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate. When an operator deploys an ACME-compatible web server, the experience would be something like this:The ACME client prompts the operator for the intended domain name(s)
that the web server is to stand for.The ACME client presents the operator with a list of CAs from which it could
get a certificate.
(This list will change over time based on the capabilities of CAs and updates to ACME configuration.)
The ACME client might prompt the operator for
payment information at this point.The operator selects a CA.In the background, the ACME client contacts the CA and requests that
a certificate be issued for the intended domain name(s).Once the CA is satisfied, the certificate is issued and the ACME client
automatically downloads and installs it, potentially notifying the
operator via e-mail, SMS, etc.The ACME client periodically contacts the CA to get updated
certificates, stapled OCSP responses, or whatever else would be
required to keep the server functional and its credentials up-to-date.The overall idea is that it’s nearly as easy to deploy with a CA-issued certificate as a self-signed certificate, and that once the operator has done so, the process is self-sustaining with minimal manual intervention. Close integration of ACME with HTTPS servers, for example, can allow the immediate and automated deployment of certificates as they are issued, optionally sparing the human administrator from additional configuration work.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 .The two main roles in ACME are “client” and “server”. The ACME client uses the protocol to request certificate management actions, such as issuance or revocation. An ACME client therefore typically runs on a web server, mail server, or some other server system which requires valid TLS certificates. The ACME server runs at a certificate authority, and responds to client requests, performing the requested actions if the client is authorized.For simplicity, in the HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.In the discussion below, we will refer to three different types of keys / key pairs:
A public key to be included in a certificate.
A key pair for which the ACME server considers the holder of the private key authorized to manage certificates for a given identifier. The same key pair may be authorized for multiple identifiers.
A secret value that can be used to demonstrate prior authorization for an identifier, in a situation where all Subject Private Keys and Account Keys are lost.ACME messaging is based on HTTPS and JSON . Since JSON is a text-based format, binary fields are Base64-encoded. For Base64 encoding, we use the variant defined in . The important features of this encoding are (1) that it uses the URL-safe character set, and (2) that “=” padding characters are stripped.Some HTTPS bodies in ACME are authenticated and integrity-protected by being encapsulated in a JSON Web Signature (JWS) object . ACME uses a profile of JWS, with the following restrictions:The JWS MUST use the JSON or Flattened JSON SerializationIf the JWS is in the JSON Serialization, it MUST NOT include more than one signature in the “signatures” arrayThe JWS Header MUST include “alg” and “jwk” fieldsACME allows a client to request certificate management actions using a set of JSON messages carried over HTTPS. In some ways, ACME functions much like a traditional CA, in which a user creates an account, adds identifiers to that account (proving control of the domains), and requests certificate issuance for those domains while logged in to the account. In ACME, the account is represented by a account key pair. The “add a domain” function is accomplished by authorizing the key pair for a given domain. Certificate issuance and revocation are authorized by a signature with the key pair.The first phase of ACME is for the client to register with the ACME server. The client generates an asymmetric key pair and associates this key pair with a set of contact information by signing the contact information. The server acknowledges the
registration by replying with a recovery token that the client can provide later to associate a new account key pair in the event that the first account key pair is lost.Before a client can issue certificates, it must establish an authorization with the server for an account key pair to act for the identifier(s) that it wishes to include in the certificate. To do this, the client must demonstrate to the server both (1) that it holds the private key of the account key pair, and (2) that it has authority over the identifier being claimed.Proof of possession of the account key is built into the ACME protocol. All messages from the client to the server are signed by the client, and the server verifies them using the public key of the account key pair.To verify that the client controls the identifier being claimed, the server issues the client a set of challenges. Because there are many different ways to validate possession of different types of identifiers, the server will choose from an extensible set of challenges that are appropriate for the identifier being claimed. The client responds with a set of responses that tell the server which challenges the client has completed. The server then validate the challenges to check that the client has accomplished the challenge.For example, if the client requests a domain name, the server might challenge the client to provision a record in the DNS under that name, or to provision a file on a web server referenced by an A or AAAA record under that name. The server would then query the DNS for the record in question, or send an HTTP request for the file. If the client provisioned the DNS or the web server as expected, then the server considers the client authorized for the domain name.Once the client has authorized an account key pair for an identifier, it can use the key pair to authorize the issuance of certificates for the identifier. To do this, the client sends a PKCS#10 Certificate Signing Request (CSR) to the server (indicating the identifier(s) to be included in the issued certificate), a set of links to any required authorizations, and a signature over the CSR by the private key of the account key pair.If the server agrees to issue the certificate, then it creates the certificate and provides it in its response. The certificate is assigned a URI, which the client can use to fetch updated versions of the certificate.To revoke a certificate, the client simply sends a revocation request, signed with an authorized key pair, and the server indicates whether the request has succeeded.Note that while ACME is defined with enough flexibility to handle different types of identifiers in principle, the primary use case addressed by this document is the case where domain names are used as identifiers. For example, all of the identifier validation challenges described in Section {identifier-validation-challenges} below address validation of domain names. The use of ACME for other protocols will require further specification, in order to describe how these identifiers are encoded in the protocol, and what types of validation challenges the server might require.In this section, we describe the certificate management functions that ACME enables:RegistrationKey AuthorizationCertificate IssuanceCertificate RevocationEach of these functions is accomplished by the client sending a sequence of HTTPS requests to the server, carrying JSON messages. Each subsection below describes the message formats used by the function, and the order in which messages are sent.ACME is structured as a REST application with a few types of resources:Registration resources, representing information about an account keyAuthorization resources, representing an account key’s authorization to act for an identifierChallenge resources, representing a challenge to prove control of an identifierCertificate resources, representing issued certificatesA “new-registration” resourceA “new-authorization” resourceA “new-certificate” resourceIn general, the intent is for authorization and certificate resources to contain only public information, so that CAs may publish these resoruces to document what certificates have been issued and how they were authorized. Non-public information, such as
contact information, is stored in registration resources.In order to accomplish ACME transactions, a client needs to have the server’s new-registration, new-authorization, and new-ceritificate URIs; the remaining URIs are provided to the client as a result of requests to these URIs. To simplify
configuration, ACME uses the “next” link relation to indicate URI to contact for the next step in processing: From registration to authorization, and from authorization to certificate issuance. In this way, a client need only be configured with the registration URI.The “up” link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs. It is also used from certificate resources to indicate a resource from which the client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource.The following diagram illustrates the relations between resources on an ACME server. The solid lines indicate link relations, and the dotted lines correspond to relationships expressed in other ways, e.g., the Location header in a 201 (Created) response.The remainder of this section provides the details of how these resources are structured and how the ACME protocol makes use of them.All ACME requests with a non-empty body MUST encapsulate the body in a JWS object, signed using the account key pair. The server MUST verify the JWS before processing the request. (For readability, however, the examples below omit this encapsulation.) Encapsulating request bodies in JWS provides a simple authentication of requests by way of key continuity.Note that this implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive.The following table illustrates a typical sequence of requests required to establish a new account with the server, prove control of an identifier, issue a certificate, and fetch an updated certificate some time after issuance. The “->” is a mnemonic for
a Location header pointing to a created resource.ActionRequestResponseRegisterPOST new-reg201 -> regRequest challengesPOST new-authz201 -> authzAnswer challengesPOST challenge200Poll for statusGET authz200Request issuanePOST new-cert201 -> certCheck for new certGET cert200Errors can be reported in ACME both at the HTTP layer and within ACME payloads. ACME servers can return responses with an HTTP error response codes (4XX or 5XX). For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed).When the server responds with an error status, it SHOULD provide additional information using problem document . The “type”, “detail”, and “instance” fields MUST be populated. To facilitate automatic response to errors, this document defines the following standard tokens for use in the “type” field (within the “urn:acme:” namespace):CodeSemanticmalformedThe request message was malformedunauthorizedThe client lacks sufficient authorizationserverInternalThe server experienced an internal errorbadCSRThe CSR is unacceptable (e.g., due to a short key)Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization.TODO: Flesh out errors and syntax for themAn ACME registration resource represents a set of metadata associated to an account key pair, most importantly contact information and a recovery token. Registration resources have the following structure:
The public key of the account key pair, encoded as a JSON Web Key object .
An array of URIs that the server can use to contact the client for issues related to this authorization. For example, the server may wish to notify the client about server-initiated revocation, or check with the client on future authorizations (see the “recoveryContact” challenge type).
An opaque token that the client can present to demonstrate that it participated in a prior authorization transaction.A client creates a new account with the server by sending a POST request to the server’s new-registration URI. The body of the request is a registration object containing only the “contact” field.The server MUST ignore any values provided in the “key” or “recoveryToken” fields, as well as any other fields that it does not recognize. If new fields are specified in the future, the specification of those fields MUST describe whether they may be
provided by the client.The server creates a registration object with the included contact information. The “key” element of the registration is set to the public key used to verify the JWS (i.e., the “jwk” element of the JWS header). The server also provides a random
recovery token. The server returns this registration object in a 201 (Created) response, with the registration URI in a Location header field. The server may also indicate its new-authorization URI using the “next” link relation.If the client wishes to update this information in the future, it sends a POST request with updated information to the registration URI. The server MUST ignore any updates to the “key” or “recoveryToken” fields, and MUST verify that the request is signed
with the private key corresponding to the “key” field of the request before updating the registration.Servers SHOULD NOT respond to GET requests for registration resources, since these requests not authenticated.An ACME authorization resource represents server’s authorization for an account key pair to represent an identifier. In addition to a public key and identifier, an authorization includes several metadata fields, such as the status of the authorization (e.g., “pending”, “valid”, or “revoked”) and which challenges were used to validate possession of the identifier.The structure of an ACME authorization resource is as follows:
The identifier that the account key is authorized to represent
The type of identifier.
The identifier itself.
The public key of the account key pair, encoded as a JSON Web Key object .
The status of this authorization. Possible values are: “pending”, “valid”, and “invalid”. If this field is missing, then the default value is “pending”.
The date after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 .
The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations). For final authorizations, the challenges that were used. Each key in the dictionary is a type of challenge, and the value is a dictionary with parameters required to validate the challenge, as specified in Section {identifier-validation-challenges}.
A collection of sets of challenges, each of which would be sufficient to prove possession of the identifier. Clients complete a set of challenges that that covers at least one set in this array. Challenges are identified by their indices in the challenges array. If no “combinations” element is included in an authorization object, the client completes all challenges.The only type of identifier defined by this specification is a fully-qualified domain name (type: “dns”). The value of the identifier MUST be the ASCII representation of the domain name.The key authorization process establishes the authorization of an account key pair to manage certificates for a given identifier. This process must assure the server of two things: First, that the client controls the private key of the key pair, and second, that the client holds the identifier in question. This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers), or to associate multiple key pairs with an identifier (e.g., to allow multiple entities to manage certificates).As illustrated by the figure in the overview section above, the authorization process proceeds in two phases. The client first requests a new authorization, and then the server issues challenges that the client responds to.To begin the key authorization process, the client sends a POST request to the server’s new-authorization resource. The body of the POST request MUST contain a JWS object, whose payload is a partial authorization object. This JWS object MUST contain only the “identifier” field, so that the server knows what identifier is being authorized. The client MAY provide contact information in the “contact” field in this or any subsequent request.Before processing the authorization further, the server SHOULD determine whether it is willing to issue certificates for the identifier. For example, the server should check that the identifier is of a supported type. Servers might also check names against a blacklist of known high-value identifiers. If the server is unwilling to issue for the identifier, it SHOULD return a 403 (Forbidden) error, with a problem document describing the reason for the rejection.If the server is willing to proceed, it builds a pending authorization object from the initial authorization object submitted by the client.“identifier” the identifier submitted by the client.“key”: the key used to verify the client’s JWS request (i.e., the contents of the “jwk” field in the JWS header)“status”: SHOULD be “pending” (MAY be omitted)“challenges” and “combinations”: As selected by the server’s policy for this identifierThe “expires” field MUST be absent.The server allocates a new URI for this authorization, and returns a 201 (Created) response, with the authorization URI in a Location header field, and the JSON authorization object in the body.The client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the “challenges” dictionary. For example, if the client wishes to complete the “simpleHttps” challenge, it needs to provide the “path” component. (This is also the stage where the client should perform any actions required by the challenge.)The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, carried in a POST request to the challenge URI (not authorization URI or the new-authorization URI). This allows the client to send information only for challenges it is responding to.For example, if the client were to respond to the “simpleHttps” challenge in the above authorization, it would send the following request:The server updates the authorization document by updating its representation of the challenge with the response fields provided by the client. The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 response including the updated challenge.Presumably, the client’s responses provide the server with enough information to validate one or more challenges. The server is said to “finalize” the authorization when it has completed all the validations it is going to complete, and assigns the authorization a status of “valid” or “invalid”, corresponding to whether it considers the account key authorized for the identifier. If the final state is “valid”, the server MUST add an “expires” field to the authorization. When finalizing an authorization, the server MAY remove the “combinations” field (if present), remove any unfulfilled challenges, or add a “recoveryToken” field.Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is finalized. For challenges where the client can tell when the server has validated the challenge (e.g., by seeing an HTTP or DNS request from the server), the client SHOULD NOT begin polling until it has seen the validation request from the server.To check on the status of an authorization, the client sends a GET request to the authorization URI, and the server responds with the current authorization object. To provide some degree of control over polling, the server MAY provide a Retry-After header field to indicate how long it expect to take in finalizing the response.A recovery token is a fallback authentication mechanism. In the event that a client loses all other state, including authorized key pairs and key pairs bound to certificates, the client can use the recovery token to prove that it was previously authorized for the identifier in question.This mechanism is necessary because once an ACME server has issued an Authorization Key for a given identifier, that identifier enters a higher-security state, at least with respect the ACME server. That state exists to protect against attacks such as DNS hijacking and router compromise which tend to inherently defeat all forms of Domain Validation. So once a domain has begun using ACME, new DV-only authorization will not be performed without proof of continuity via possession of an Authorized Private Key or potentially a Subject Private Key for that domain.This higher state of security poses some risks. From time to time, the administrators and owners of domains may lose access to keys they have previously had issued or certified, including Authorized private keys and Subject private keys. For instance, the disks on which this key material is stored may suffer failures, or passphrases for these keys may be forgotten. In some cases, the security measures that are taken to protect this sensitive data may contribute to its loss.Recovery Tokens and Recovery Challenges exist to provide a fallback mechanism to restore the state of the domain to the server-side administrative security state it was in prior to the use of ACME, such that fresh Domain Validation is sufficient for reauthorization.Recovery tokens are therefore only useful to an attacker who can also perform Domain Validation against a target domain, and as a result client administrators may choose to handle them with somewhat fewer security precautions than Authorized and Subject private keys, decreasing the risk of their loss.Recovery tokens come in several types, including high-entropy passcodes (which need to be safely preserved by the client admin) and email addresses (which are inherently hard to lose, and which can be used for verification, though they may be a little less secure).Recovery tokens are employed in response to Recovery Challenges. Such challenges will be available if the server has issued Recovery Tokens for a given domain, and the combination of a Recovery Challenge and a domain validation Challenge is a plausible alternative to other challenge sets for domains that already have extant Authorized keys.The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier. The client makes this request by sending a POST request to the server’s new-certificate resource. The body of the POST is a JWS object whose JSON payload contains a Certificate Signing Request (CSR) and set of authorization URIs. The CSR encodes the parameters of the requested certificate; authority to issue is demonstrated by the JWS signature and the linked authorizations.
A CSR encoding the parameters for the certificate being requested. The CSR is sent in base64-encoded version the DER format. (Note: This field uses the same modified base64-encoding rules used elsewhere in this document, so it is different from PEM.)
An array of URIs for authorization resources.HTTP/1.1 201 Created
Content-Type: application/pkix-cert
Link: https://example.com/acme/ca-cert;rel=”up”;title=”issuer”
Location: https://example.com/acme/cert/asdf[DER-encoded certificate]POST /acme/cert/asdf HTTP/1.1
Host: example.com{
“revoke”: “now”,
“authorizations”: [
“https://example.com/acme/authz/asdf”
]
}
/* Signed as JWS */HTTP/1.1 200 OK
Content-Length: 0— or —HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en{
“type”: “urn:acme:error:unauthorized”
“detail”: “No authorization provided for name example.net”
“instance”: “http://example.com/doc/unauthorized”
}{
“type”: “simpleHttps”,
“token”: “evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ+PCt92wr+oA”
}{
“type”: “simpleHttps”,
“path”: “6tbIMBC5Anhl5bOlWT5ZFA”
}{
“type”: “dvsni”,
“r”: “Tyq0La3slT7tqQ0wlOiXnCY2vyez7Zo5blgPJ1xt5xI”,
“nonce”: “a82d5ff8ef740d12881f6d3c2277ab2e”
}{
“type”: “dvsni”,
“s”: “9dbjsl3gTAtOnEtKFEmhS6Mj-ajNjDcOmRkp3Lfzm3c”
}{
“type”: “recoveryContact”,
“activationURL” : “https://example.ca/sendrecovery/a5bd99383fb0”,
“successURL” : “https://example.ca/confirmrecovery/bb1b9928932”,
“contact” : “c****n@example.com”
}{
“type”: “recoveryContact”,
“token”: “23029d88d9e123e”
}{
“type”: “recoveryToken”
}{
“type”: “recoveryToken”,
“token”: “23029d88d9e123e”
}{
“type”: “proofOfPossession”,
“alg”: “RS256”,
“nonce”: “eET5udtV7aoX8Xl8gYiZIA”,
“hints” : {
“jwk”: {
“kty”: “RSA”,
“e”: “AQAB”,
“n”: “KxITJ0rNlfDMAtfDr8eAw…fSSoehDFNZKQKzTZPtQ”
},
“certFingerprints”: [
“93416768eb85e33adc4277f4c9acd63e7418fcfe”,
“16d95b7b63f1972b980b14c20291f3c0d1855d95”,
“48b46570d9fc6358108af43ad1649484def0debf”
],
“subjectKeyIdentifiers”: [
“d0083162dcc4c8a23ecb8aecbd86120e56fd24e5”
],
“serialNumbers”: [34234239832, 23993939911, 17],
“issuers”: [
“C=US, O=SuperT LLC, CN=SuperTrustworthy Public CA”,
“O=LessTrustworthy CA Inc, CN=LessTrustworthy But StillSecure”
],
“authorizedFor”: [“www.example.com”, “example.net”]
}
}{
“type”: “proofOfPossession”,
“nonce”: “eET5udtV7aoX8Xl8gYiZIA”,
“signature”: {
“alg”: “RS256”,
“nonce”: “eET5udtV7aoX8Xl8gYiZIA”,
“sig”: “KxITJ0rNlfDMAtfDr8eAw…fSSoehDFNZKQKzTZPtQ”,
“jwk”: {
“kty”: “RSA”,
“e”: “AQAB”,
“n”: “KxITJ0rNlfDMAtfDr8eAw…fSSoehDFNZKQKzTZPtQ”
}
}
}{
“type”: “dns”,
“token”: “17817c66b60ce2e4012dfad92657527a”
}_acme-challenge.example.com. IN TXT “17817c66b60ce2e4012dfad92657527a”{
“type”: “dns”
}~~~~~~~~~~To validate a DNS challenge, the server queries for TXT records under the validation domain name. If it receives a record whose contents match the token in the challenge, then the validation succeeds. Otherwise, the validation fails.For future work:EmailDNSSECWHOISTODORegister .well-known pathCreate identifier validation method registryRegistries of syntax tokens, e.g., message types / error types?TODOGeneral authorization storyPoP nonce entropyToC/ToU; duration of key authorizationClients need to protect recovery keyCA needs to perform a very wide range of issuance policy enforcement and sanity-check stepsParser safety (for JSON, JWK, ASN.1, and any other formats that can be parsed by the ACME server)This document draws on many concepts established by Eric Rescorla’s “Automated Certificate Issuance Protocol” draft. Martin Thomson provided helpful guidance in the use of HTTP.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
PKCS #10: Certification Request Syntax Version 1.5RSA Laboratories East20 Crosby DriveBedfordMA01730(617) 687-7000burt@rsa.com
Security
public key cryptography standardsPKCS #9: Selected Object Classes and Attribute Types Version 2.0This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.PKCS #10: Certification Request Syntax Specification Version 1.7This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.Date and Time on the Internet: TimestampsClearswift Corporation1310 WatersideArlington Business ParkThealeReadingRG7 4SAUK+44 11 8903 8903+44 11 8903 9000GK@ACM.ORGSun Microsystems1050 Lakes Drive, Suite 250West CovinaCA91790USAchris.newman@sun.com
This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar.
Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished NamesThe X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Web LinkingThis document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]URI TemplateA URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.JSON Merge PatchThis specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.Problem Details for HTTP APIsThis document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1].JSON Web Algorithms (JWA)The JSON Web Algorithms (JWA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.JSON Web Key (JWK)A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification.JSON Web Signature (JWS)JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.HTTP Over TLSThis memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.