| Internet-Draft | SPKAC | October 2022 |
| Leggett & van Gulik | Expires 25 April 2023 | [Page] |
- Workgroup:
- Internet Engineering Task Force
- Internet-Draft:
- draft-leggett-spkac-01
- Published:
- Intended Status:
- Informational
- Expires:
Signed Public Key and Challenge
Abstract
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.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 April 2023.¶
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
1. 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.¶
1.1. 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 [RFC2119].¶
1.2. Historical
The SPKAC protocol was originally used by the Netscape web browser as part of their implementation of what eventually became the HTML5 [W3C.REC-html5-20141028] 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.¶
2. 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) [X.690], and are defined below.¶
2.1. spki
The spki is a SubjectPublicKeyInfo as defined in RFC 5912 [RFC5912], and consists of an ASN.1 sequence containing the algorithm used by the public key, and the public key itself.¶
2.2. 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.¶
2.3. 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.¶
2.4. signatureAlgorithm
The signatureAlgorithm is an AlgorithmIdentifier defined in RFC 5911 [RFC5911], and represents the algorithm used to sign the publicKeyAndChallenge.¶
2.5. 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.¶
3. 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.¶
SPKAC-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier{}, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
SubjectPublicKeyInfo, SignatureAlgorithms
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)};
PublicKeyAndChallenge ::= SEQUENCE
{
spki SubjectPublicKeyInfo,
challenge IA5String
}
SignedPublicKeyAndChallenge ::= SEQUENCE
{
publicKeyAndChallenge PublicKeyAndChallenge,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{SignatureAlgorithms}},
signature BIT STRING
}
END
¶
4. Example
The following example consists of a Base64 [RFC4648] encoded SPKAC message signed with an RSA key [RFC8017] using the SHA256 message-digest [RFC6234] algorithm.¶
MIIESTCCAjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC9wmyQidBwnIN3 08UwRlTX2mB9g1a05IR6l9TOGmSz6BV5YYbavXdq38EA7dw/44U/P9edRNIwFTMPLWIb hkDYMZkuziyovhBji8c5gUb09Flplc1aWO8V4u5kjEY6clusYVSxL+j0GU3NXW2k2AC4 +Ts8Y/sE9kfqWb5QzTI2Tz1UqRr6oE2G65LhFhgkg/yafnvOsh+B8nNwdcPwbqzPW8qN FrDqppDg9sm5PbrfGY9xTeBYKq0AVv//qyG5YgqjNZPIPC4mRQfx/IPbcMJXNIf6iRQi LniAxFuBmO3Ohog8rufUezWrA5d3f1sorTozkKxRECwnzgMcKmzcyZtENbkrNuL1BbDq hwDs3xf9ilbwkiRx1BOWrPCEXZneS96iFRkEMkw2AcIQIqiDNSStpOt8jyKX4sRdUO3t fagCZ1QcL2Dmyab5aypTr/eVx/xj3sZsrQCy89BlOsSN9GTBbIQeui97PiA6hmVFUWbG La2TdZH+Bnjjc8OiZPF5YH9uQo1Z9xD+fxcL6xOQW35/JyJ7AtGa1SIut0q3WQ4S93wA B/DOADc9GWl4mWB/2goLDsCUWXSHYs2czS/2a/Lh9MKQsDKLQbEMncxaq3TVBG7Urq9S RnmemguaWjvoni0o725nWi/j5H6AtOZYoFGmccjxraSAVGWS4r+0X3qSZQIDAQABFglj aGFsbGVuZ2UwDQYJKoZIhvcNAQELBQADggIBAJJgmBFMD+2AqkQpD/2AgCcoKNkRmcD8 EkHQY+5WN80+ogaWf5VcDU3ycP2554x95EPLhclqrX9xbzUemuUoNiR/sPyhxl0Pr7OP tKqulW6QvT+YCcyrbILR1jE8lhVSENkT/fL6U9J4NPd7qGB0OFiTv9tAT1huzzuXgx67 6T8Y5mb9XVk0C6CCGEoDxSKI2n3/nbkdyyXlq1uFphwVCXEBUvrndD8y3vKd8rhtGyvz 8cTg2q/mHmSHldwwmfksaRNwh9mxOKerLUQ5pFM68HODOnJHFs/D26GQlwINfVqrVnI+ oCA/VFFz/QO4minT7zuDSGa/cFdiPWj3d//Gz02ppUIHk8RVKrdGgTf/efQmbP2zLEfa AfTUlSjVliVDqw5SRG6QJYrvz80pfZcz13BY3pkN5lnAcuA8Ld5Gb/YVfiJkiefvMt9t 753pe9Yxv8iU6PKfQO8UbiGbPfEDP5bQ1EJPX0rdmvX7T85hwR7LXC5iUBs2xdahTfDg oZTZ/12fSoNwkdgmYURmy/fAEOnVHIn5Gj/LKu8ii2UOzWktbAnz4f30MeuFeaBx5h9v e/nELQnvsPiZgIDFdKYdXb8yJRTgg9ahYdPhEC/u1RIJFxs4sRmRfZwY7qATssLhnL9Z DtDuuZxJft+sn5swpiepSiekGvw20fsP6tRD4nu0¶
The following section shows the decoded version of the above SKPAC message.¶
Netscape SPKI:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:bd:c2:6c:90:89:d0:70:9c:83:77:d3:c5:30:46:
54:d7:da:60:7d:83:56:b4:e4:84:7a:97:d4:ce:1a:
64:b3:e8:15:79:61:86:da:bd:77:6a:df:c1:00:ed:
dc:3f:e3:85:3f:3f:d7:9d:44:d2:30:15:33:0f:2d:
62:1b:86:40:d8:31:99:2e:ce:2c:a8:be:10:63:8b:
c7:39:81:46:f4:f4:59:69:95:cd:5a:58:ef:15:e2:
ee:64:8c:46:3a:72:5b:ac:61:54:b1:2f:e8:f4:19:
4d:cd:5d:6d:a4:d8:00:b8:f9:3b:3c:63:fb:04:f6:
47:ea:59:be:50:cd:32:36:4f:3d:54:a9:1a:fa:a0:
4d:86:eb:92:e1:16:18:24:83:fc:9a:7e:7b:ce:b2:
1f:81:f2:73:70:75:c3:f0:6e:ac:cf:5b:ca:8d:16:
b0:ea:a6:90:e0:f6:c9:b9:3d:ba:df:19:8f:71:4d:
e0:58:2a:ad:00:56:ff:ff:ab:21:b9:62:0a:a3:35:
93:c8:3c:2e:26:45:07:f1:fc:83:db:70:c2:57:34:
87:fa:89:14:22:2e:78:80:c4:5b:81:98:ed:ce:86:
88:3c:ae:e7:d4:7b:35:ab:03:97:77:7f:5b:28:ad:
3a:33:90:ac:51:10:2c:27:ce:03:1c:2a:6c:dc:c9:
9b:44:35:b9:2b:36:e2:f5:05:b0:ea:87:00:ec:df:
17:fd:8a:56:f0:92:24:71:d4:13:96:ac:f0:84:5d:
99:de:4b:de:a2:15:19:04:32:4c:36:01:c2:10:22:
a8:83:35:24:ad:a4:eb:7c:8f:22:97:e2:c4:5d:50:
ed:ed:7d:a8:02:67:54:1c:2f:60:e6:c9:a6:f9:6b:
2a:53:af:f7:95:c7:fc:63:de:c6:6c:ad:00:b2:f3:
d0:65:3a:c4:8d:f4:64:c1:6c:84:1e:ba:2f:7b:3e:
20:3a:86:65:45:51:66:c6:2d:ad:93:75:91:fe:06:
78:e3:73:c3:a2:64:f1:79:60:7f:6e:42:8d:59:f7:
10:fe:7f:17:0b:eb:13:90:5b:7e:7f:27:22:7b:02:
d1:9a:d5:22:2e:b7:4a:b7:59:0e:12:f7:7c:00:07:
f0:ce:00:37:3d:19:69:78:99:60:7f:da:0a:0b:0e:
c0:94:59:74:87:62:cd:9c:cd:2f:f6:6b:f2:e1:f4:
c2:90:b0:32:8b:41:b1:0c:9d:cc:5a:ab:74:d5:04:
6e:d4:ae:af:52:46:79:9e:9a:0b:9a:5a:3b:e8:9e:
2d:28:ef:6e:67:5a:2f:e3:e4:7e:80:b4:e6:58:a0:
51:a6:71:c8:f1:ad:a4:80:54:65:92:e2:bf:b4:5f:
7a:92:65
Exponent: 65537 (0x10001)
Challenge String: challenge
Signature Algorithm: sha256WithRSAEncryption
92:60:98:11:4c:0f:ed:80:aa:44:29:0f:fd:80:80:27:28:28:
d9:11:99:c0:fc:12:41:d0:63:ee:56:37:cd:3e:a2:06:96:7f:
95:5c:0d:4d:f2:70:fd:b9:e7:8c:7d:e4:43:cb:85:c9:6a:ad:
7f:71:6f:35:1e:9a:e5:28:36:24:7f:b0:fc:a1:c6:5d:0f:af:
b3:8f:b4:aa:ae:95:6e:90:bd:3f:98:09:cc:ab:6c:82:d1:d6:
31:3c:96:15:52:10:d9:13:fd:f2:fa:53:d2:78:34:f7:7b:a8:
60:74:38:58:93:bf:db:40:4f:58:6e:cf:3b:97:83:1e:bb:e9:
3f:18:e6:66:fd:5d:59:34:0b:a0:82:18:4a:03:c5:22:88:da:
7d:ff:9d:b9:1d:cb:25:e5:ab:5b:85:a6:1c:15:09:71:01:52:
fa:e7:74:3f:32:de:f2:9d:f2:b8:6d:1b:2b:f3:f1:c4:e0:da:
af:e6:1e:64:87:95:dc:30:99:f9:2c:69:13:70:87:d9:b1:38:
a7:ab:2d:44:39:a4:53:3a:f0:73:83:3a:72:47:16:cf:c3:db:
a1:90:97:02:0d:7d:5a:ab:56:72:3e:a0:20:3f:54:51:73:fd:
03:b8:9a:29:d3:ef:3b:83:48:66:bf:70:57:62:3d:68:f7:77:
ff:c6:cf:4d:a9:a5:42:07:93:c4:55:2a:b7:46:81:37:ff:79:
f4:26:6c:fd:b3:2c:47:da:01:f4:d4:95:28:d5:96:25:43:ab:
0e:52:44:6e:90:25:8a:ef:cf:cd:29:7d:97:33:d7:70:58:de:
99:0d:e6:59:c0:72:e0:3c:2d:de:46:6f:f6:15:7e:22:64:89:
e7:ef:32:df:6d:ef:9d:e9:7b:d6:31:bf:c8:94:e8:f2:9f:40:
ef:14:6e:21:9b:3d:f1:03:3f:96:d0:d4:42:4f:5f:4a:dd:9a:
f5:fb:4f:ce:61:c1:1e:cb:5c:2e:62:50:1b:36:c5:d6:a1:4d:
f0:e0:a1:94:d9:ff:5d:9f:4a:83:70:91:d8:26:61:44:66:cb:
f7:c0:10:e9:d5:1c:89:f9:1a:3f:cb:2a:ef:22:8b:65:0e:cd:
69:2d:6c:09:f3:e1:fd:f4:31:eb:85:79:a0:71:e6:1f:6f:7b:
f9:c4:2d:09:ef:b0:f8:99:80:80:c5:74:a6:1d:5d:bf:32:25:
14:e0:83:d6:a1:61:d3:e1:10:2f:ee:d5:12:09:17:1b:38:b1:
19:91:7d:9c:18:ee:a0:13:b2:c2:e1:9c:bf:59:0e:d0:ee:b9:
9c:49:7e:df:ac:9f:9b:30:a6:27:a9:4a:27:a4:1a:fc:36:d1:
fb:0f:ea:d4:43:e2:7b:b4
¶
5. 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 [RFC8126] 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.¶
6. 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.¶
6.1. 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 [RFC6151] 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.¶
6.2. 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 [RFC8446].¶
6.3. 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.¶
7. References
7.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- [RFC4648]
- Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
- [RFC5911]
- Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, , <https://www.rfc-editor.org/info/rfc5911>.
- [RFC5912]
- Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, , <https://www.rfc-editor.org/info/rfc5912>.
- [RFC6151]
- Turner, S., "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, , <https://www.rfc-editor.org/info/rfc6151>.
- [RFC6234]
- Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>.
- [RFC8017]
- Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, , <https://www.rfc-editor.org/info/rfc8017>.
- [RFC8446]
- Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
- [W3C.REC-html5-20141028]
- Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", World Wide Web Consortium Recommendation REC-html5-20141028, , <http://www.w3.org/TR/2014/REC-html5-20141028>.
- [X.690]
- authSurName, authInitials., "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).", ITU-T Recommendation X.690 (2002) ISO/IEC 8825-1:2002, .
7.2. Informative References
- [RFC8126]
- Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
