Pepperpot Media

London UK minfrin@sharp.fm

WebWeaving Internet Engineering

Leiden NL dirkx@webweaving.org

General Internet Engineering Task Force spkac This memo describes the Signed Public Key and Challenge (SPKAC), a syntax to provide Proof-of-Possession of a Private Key to support federated (client) certificate enrolment.

Introduction During a certificate enrollment process between a client (browser) and a Certification Authority (CA), possibly via a Registration Authority (RA), the CA requires that the client provide proof-of-possession of the private key corresponding to the public key of the certificate that will be signed by the CA. The Signed Public Key and Challenge consists of a public key and an optional challenge, collectively signed by the private key of the end entity requesting certification.

Requirements Language 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.

Historical The SPKAC protocol was originally used by the Netscape web browser as part of their implementation of what eventually became the HTML5 keygen tag. The keygen tag allowed a web browser to request a (client) certificate from a CA over the world wide web, and the SPKAC protocol ensured the web browser possessed the private key corresponding to the public key being used with the certificate signed by the CA. Storage of the private key would typically be in a file based keystore; or through a PKCS interface on a hardware token (which may, or may not, have generated the private key and signed the SPKAC inside that hardware enclave). For a long time the Signed Public Key and Challenge was a de facto standard widely implemented but not standardised. The purpose of this RFC is to document the existing use of the protocol, address security implementation weaknesses in common implementations, and formalise the protocol into a standard. Note that, in 2015, Google unilaterally decided to retire keygen tag support from the Chrome web browser. Prior to this; SPKAC was widely used by both centralised CAs (that would issue personal digital x509 certificates) as well as in local enterprise and federated settings. This removal has left the web community with no standard way, de facto or otherwise, to distribute soft and hard tokens to clients.

Signed Public Key and Challenge Profile The parts that make up the Signed Public Key and Challenge are encoded using the ASN.1 distinguished encoding rules (DER), and are defined below.

spki The spki is a SubjectPublicKeyInfo as defined in RFC 5912, and consists of an ASN.1 sequence containing the algorithm used by the public key, and the public key itself.

challenge The challenge is an ASN.1 IA5String, and MUST consist of a value provided by the CA that is difficult to predict. This value will be encoded into the SPKAC by the end entity, signed by the private key corresponding to the public key, and returned to the CA.

publicKeyAndChallenge The publicKeyAndChallenge is an ASN.1 sequence of the spki and challenge defined above. This value is signed using the signatureAlgorithm and public key to produce the signature below.

signatureAlgorithm The signatureAlgorithm is an AlgorithmIdentifier defined in RFC 5911, and represents the algorithm used to sign the publicKeyAndChallenge.

signature The signature is an ASN.1 bit string containing the signature of the ASN.1 DER encoded publicKeyAndChallenge, using the algorithm specified by signatureAlgorithm.

ASN.1 Module SPKAC This appendix includes all of the ASN.1 type and value definitions contained in this document in the form of the ASN.1 module SPKAC.

Example The following example consists of a Base64 encoded SPKAC message signed with an RSA key using the SHA256 message-digest algorithm. The following section shows the decoded version of the above SKPAC message.

IANA Considerations IANA is asked to assign the value "spkac" below { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) } as per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26 for the identifier of the ASN.1 SPKAC schema, and to add this to the ASN.1 definition in this specification. All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

Security Considerations The aim of SPKAC is that no adversary can convince a CA to sign a certificate using the private key other than that intended. An adversary is any entity other than the end entity and the CA attempting to establish proof-of-possession.

Use of the MD5 Message-Digest Algorithm Historically the formal definition of the HTML keygen tag specified that the MD5 message-digest algorithm be used within SPKAC requests. As defined in Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms MD5 must not be used for digital signatures. New protocols using the SPKAC protocol MUST NOT mandate the use of a fixed message-digest algorithm, and existing protocols using the SPKAC protocol SHOULD be updated to ensure the message-digest used is not fixed to a given digest.

Clear Text Challenge and Public Key Given that both the Challenge and the Public Key are encoded within the SPKAC message in clear text, to ensure privacy of the data in transit additional steps SHOULD be taken to ensure that SPKAC message is delivered over a secure transport, such as TLS.

UI/UX Denial of Service Design Issues When the generation of an SPKAC message is triggered by a remote entity, such as a CA triggering the generation of an SPKAC message in a browser as part of a certificate request, the user interfaces in the client (browser) should take care to not allow (rogue) webpages or javascript to generate a very large number of SPKAC requests; as this is not only somewhat resource intensive; but may also deplete cryptographic quality random generator pools (historically a concern). This is especially important as most implementations will generally keep the cryptographic code and (private) key storage outside the sandbox in which the DOM and Javascript is handled. Likewise - clients (browsers) should be particularly careful when handling solicited (and unsolicited and maliciously repeated/high-volume) responses to a SPKAC submission when storing certificates and recombining certificates with keys in the key store. Especially as (historically) it was common for such request to be handled asynchronously; with the user receiving an email after, for example human approval, to pick up the signed certificate at a certain URL. Clients SHOULD make a request to the user for consent for the client to generate the SPKAC message in a clear and easy to understand manner, with cancel being the default choice should the user not understand the request.

References Normative References 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Federal Information Processing Standard, FIPS This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document updates the security considerations for the MD5 message digest algorithm. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.