Signed Public Key and Challenge
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 Public Key to support federated (client) certificate enrolment.
Introduction
During a certificate enrollment process between a client (browser) and a
certificate authority, the certificate authority requires that the client
provide proof-of-possession of the public key of the certificate
that will be signed by the certificate authority.
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 certificate authority over the world wide web, and the SPKAC protocol
ensured the web browser possessed the key being signed by the certificate
authority. 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 SPAC 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 certificate authorities (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 certificate authority 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 certificate authority.
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 certificate authority
to sign a certificate using the public key other than that intended. An
adversary is any entity other than the end entity and the certificate authority
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 certificate authority 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 keygen 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
Key words for use in RFCs to Indicate Requirement Levels
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.
US Secure Hash Algorithms (SHA and HMAC-SHA)
The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.
The Base16, Base32, and Base64 Data Encodings
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]
New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
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.
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
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.
Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms
This document updates the security considerations for the MD5 message digest algorithm.
PKCS #1: RSA Cryptography Specifications Version 2.2
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.
The Transport Layer Security (TLS) Protocol Version 1.3
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.
HTML5
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
Informative References
Guidelines for Writing an IANA Considerations Section in RFCs
Many 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).
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.
This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.