idnits 2.17.1 draft-leggett-spkac-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (6 March 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Leggett, Ed. 3 Internet-Draft Pepperpot Media 4 Intended status: Informational D.W. van Gulik 5 Expires: 7 September 2020 WebWeaving Internet Engineering 6 6 March 2020 8 Signed Public Key and Challenge 9 draft-leggett-spkac-00 11 Abstract 13 This memo describes the Signed Public Key and Challenge (SPKAC), a 14 syntax to provide Proof-of-Possession of a Public Key to support 15 federated (client) certificate enrolment. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 7 September 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 1.2. Historical . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Signed Public Key and Challenge Profile . . . . . . . . . . . 3 54 2.1. spki . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. challenge . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3. publicKeyAndChallenge . . . . . . . . . . . . . . . . . . 3 57 2.4. signatureAlgorithm . . . . . . . . . . . . . . . . . . . 4 58 2.5. signature . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. ASN.1 Module SPKAC . . . . . . . . . . . . . . . . . . . . . 4 60 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6.1. Use of the MD5 Message-Digest Algorithm . . . . . . . . . 7 64 6.2. Clear Text Challenge and Public Key . . . . . . . . . . . 8 65 6.3. UI/UX Denial of Service Design Issues . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 During a certificate enrollment process between a client (browser) 74 and a certificate authority, the certificate authority requires that 75 the client provide proof-of-possession of the public key of the 76 certificate that will be signed by the certificate authority. 78 The Signed Public Key and Challenge consists of a public key and an 79 optional challenge, collectively signed by the private key of the end 80 entity requesting certification. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 1.2. Historical 90 The SPKAC protocol was originally used by the Netscape web browser as 91 part of their implementation of what eventually became the HTML5 92 [W3C.REC-html5-20141028] keygen tag. The keygen tag allowed a web 93 browser to request a (client) certificate from a certificate 94 authority over the world wide web, and the SPKAC protocol ensured the 95 web browser possessed the key being signed by the certificate 96 authority. Storage of the private key would typically be in a file 97 based keystore; or through a PKCS interface on a hardware token 98 (which may, or may not, have generated the private key and signed the 99 SPAC inside that hardware enclave). 101 For a long time the Signed Public Key and Challenge was a de facto 102 standard widely implemented but not standardised. The purpose of 103 this RFC is to document the existing use of the protocol, address 104 security implementation weaknesses in common implementations, and 105 formalise the protocol into a standard. 107 Note that, in 2015, Google unilaterally decided to retire keygen tag 108 support from the Chrome web browser. Prior to this; SPKAC was widely 109 used by both centralised certificate authorities (that would issue 110 personal digital x509 certificates) as well as in local enterprise 111 and federated settings. This removal has left the web community with 112 no standard way, de facto or otherwise, to distribute soft and hard 113 tokens to clients. 115 2. Signed Public Key and Challenge Profile 117 The parts that make up the Signed Public Key and Challenge are 118 encoded using the ASN.1 distinguished encoding rules (DER) [X.690], 119 and are defined below. 121 2.1. spki 123 The spki is a SubjectPublicKeyInfo as defined in RFC 5912 [RFC5912], 124 and consists of an ASN.1 sequence containing the algorithm used by 125 the public key, and the public key itself. 127 2.2. challenge 129 The challenge is an ASN.1 IA5String, and MUST consist of a value 130 provided by the certificate authority that is difficult to predict. 131 This value will be encoded into the SPKAC by the end entity, signed 132 by the private key corresponding to the public key, and returned to 133 the certificate authority. 135 2.3. publicKeyAndChallenge 137 The publicKeyAndChallenge is an ASN.1 sequence of the spki and 138 challenge defined above. This value is signed using the 139 signatureAlgorithm and public key to produce the signature below. 141 2.4. signatureAlgorithm 143 The signatureAlgorithm is an AlgorithmIdentifier defined in RFC 5911 144 [RFC5911], and represents the algorithm used to sign the 145 publicKeyAndChallenge. 147 2.5. signature 149 The signature is an ASN.1 bit string containing the signature of the 150 ASN.1 DER encoded publicKeyAndChallenge, using the algorithm 151 specified by signatureAlgorithm. 153 3. ASN.1 Module SPKAC 155 This appendix includes all of the ASN.1 type and value definitions 156 contained in this document in the form of the ASN.1 module SPKAC. 158 SPKAC-Schema DEFINITIONS AUTOMATIC TAGS ::= 159 BEGIN 160 IMPORTS 162 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM 163 FROM AlgorithmInformation-2009 164 {iso(1) identified-organization(3) dod(6) internet(1) 165 security(5) mechanisms(5) pkix(7) id-mod(0) 166 id-mod-algorithmInformation-02(58)} 168 SubjectPublicKeyInfo, SignatureAlgorithms 169 FROM PKIX1Explicit-2009 170 {iso(1) identified-organization(3) dod(6) internet(1) 171 security(5) mechanisms(5) pkix(7) id-mod(0) 172 id-mod-pkix1-explicit-02(51)}; 174 PublicKeyAndChallenge ::= SEQUENCE 175 { 176 spki SubjectPublicKeyInfo, 177 challenge IA5String 178 } 179 SignedPublicKeyAndChallenge ::= SEQUENCE 180 { 181 publicKeyAndChallenge PublicKeyAndChallenge, 182 signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM, 183 {SignatureAlgorithms}}, 184 signature BIT STRING 185 } 187 END 189 4. Example 191 The following example consists of a Base64 [RFC4648] encoded SPKAC 192 message signed with an RSA key [RFC8017] using the SHA256 193 message-digest [RFC4634] algorithm. 195 MIIESTCCAjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC9wmyQidBwnIN3 196 08UwRlTX2mB9g1a05IR6l9TOGmSz6BV5YYbavXdq38EA7dw/44U/P9edRNIwFTMPLWIb 197 hkDYMZkuziyovhBji8c5gUb09Flplc1aWO8V4u5kjEY6clusYVSxL+j0GU3NXW2k2AC4 198 +Ts8Y/sE9kfqWb5QzTI2Tz1UqRr6oE2G65LhFhgkg/yafnvOsh+B8nNwdcPwbqzPW8qN 199 FrDqppDg9sm5PbrfGY9xTeBYKq0AVv//qyG5YgqjNZPIPC4mRQfx/IPbcMJXNIf6iRQi 200 LniAxFuBmO3Ohog8rufUezWrA5d3f1sorTozkKxRECwnzgMcKmzcyZtENbkrNuL1BbDq 201 hwDs3xf9ilbwkiRx1BOWrPCEXZneS96iFRkEMkw2AcIQIqiDNSStpOt8jyKX4sRdUO3t 202 fagCZ1QcL2Dmyab5aypTr/eVx/xj3sZsrQCy89BlOsSN9GTBbIQeui97PiA6hmVFUWbG 203 La2TdZH+Bnjjc8OiZPF5YH9uQo1Z9xD+fxcL6xOQW35/JyJ7AtGa1SIut0q3WQ4S93wA 204 B/DOADc9GWl4mWB/2goLDsCUWXSHYs2czS/2a/Lh9MKQsDKLQbEMncxaq3TVBG7Urq9S 205 RnmemguaWjvoni0o725nWi/j5H6AtOZYoFGmccjxraSAVGWS4r+0X3qSZQIDAQABFglj 206 aGFsbGVuZ2UwDQYJKoZIhvcNAQELBQADggIBAJJgmBFMD+2AqkQpD/2AgCcoKNkRmcD8 207 EkHQY+5WN80+ogaWf5VcDU3ycP2554x95EPLhclqrX9xbzUemuUoNiR/sPyhxl0Pr7OP 208 tKqulW6QvT+YCcyrbILR1jE8lhVSENkT/fL6U9J4NPd7qGB0OFiTv9tAT1huzzuXgx67 209 6T8Y5mb9XVk0C6CCGEoDxSKI2n3/nbkdyyXlq1uFphwVCXEBUvrndD8y3vKd8rhtGyvz 210 8cTg2q/mHmSHldwwmfksaRNwh9mxOKerLUQ5pFM68HODOnJHFs/D26GQlwINfVqrVnI+ 211 oCA/VFFz/QO4minT7zuDSGa/cFdiPWj3d//Gz02ppUIHk8RVKrdGgTf/efQmbP2zLEfa 212 AfTUlSjVliVDqw5SRG6QJYrvz80pfZcz13BY3pkN5lnAcuA8Ld5Gb/YVfiJkiefvMt9t 213 753pe9Yxv8iU6PKfQO8UbiGbPfEDP5bQ1EJPX0rdmvX7T85hwR7LXC5iUBs2xdahTfDg 214 oZTZ/12fSoNwkdgmYURmy/fAEOnVHIn5Gj/LKu8ii2UOzWktbAnz4f30MeuFeaBx5h9v 215 e/nELQnvsPiZgIDFdKYdXb8yJRTgg9ahYdPhEC/u1RIJFxs4sRmRfZwY7qATssLhnL9Z 216 DtDuuZxJft+sn5swpiepSiekGvw20fsP6tRD4nu0 218 The following section shows the decoded version of the above SKPAC 219 message. 221 Netscape SPKI: 222 Public Key Algorithm: rsaEncryption 223 RSA Public-Key: (4096 bit) 224 Modulus: 225 00:bd:c2:6c:90:89:d0:70:9c:83:77:d3:c5:30:46: 226 54:d7:da:60:7d:83:56:b4:e4:84:7a:97:d4:ce:1a: 227 64:b3:e8:15:79:61:86:da:bd:77:6a:df:c1:00:ed: 228 dc:3f:e3:85:3f:3f:d7:9d:44:d2:30:15:33:0f:2d: 229 62:1b:86:40:d8:31:99:2e:ce:2c:a8:be:10:63:8b: 230 c7:39:81:46:f4:f4:59:69:95:cd:5a:58:ef:15:e2: 231 ee:64:8c:46:3a:72:5b:ac:61:54:b1:2f:e8:f4:19: 232 4d:cd:5d:6d:a4:d8:00:b8:f9:3b:3c:63:fb:04:f6: 233 47:ea:59:be:50:cd:32:36:4f:3d:54:a9:1a:fa:a0: 234 4d:86:eb:92:e1:16:18:24:83:fc:9a:7e:7b:ce:b2: 235 1f:81:f2:73:70:75:c3:f0:6e:ac:cf:5b:ca:8d:16: 236 b0:ea:a6:90:e0:f6:c9:b9:3d:ba:df:19:8f:71:4d: 238 e0:58:2a:ad:00:56:ff:ff:ab:21:b9:62:0a:a3:35: 239 93:c8:3c:2e:26:45:07:f1:fc:83:db:70:c2:57:34: 240 87:fa:89:14:22:2e:78:80:c4:5b:81:98:ed:ce:86: 241 88:3c:ae:e7:d4:7b:35:ab:03:97:77:7f:5b:28:ad: 242 3a:33:90:ac:51:10:2c:27:ce:03:1c:2a:6c:dc:c9: 243 9b:44:35:b9:2b:36:e2:f5:05:b0:ea:87:00:ec:df: 244 17:fd:8a:56:f0:92:24:71:d4:13:96:ac:f0:84:5d: 245 99:de:4b:de:a2:15:19:04:32:4c:36:01:c2:10:22: 246 a8:83:35:24:ad:a4:eb:7c:8f:22:97:e2:c4:5d:50: 247 ed:ed:7d:a8:02:67:54:1c:2f:60:e6:c9:a6:f9:6b: 248 2a:53:af:f7:95:c7:fc:63:de:c6:6c:ad:00:b2:f3: 249 d0:65:3a:c4:8d:f4:64:c1:6c:84:1e:ba:2f:7b:3e: 250 20:3a:86:65:45:51:66:c6:2d:ad:93:75:91:fe:06: 251 78:e3:73:c3:a2:64:f1:79:60:7f:6e:42:8d:59:f7: 252 10:fe:7f:17:0b:eb:13:90:5b:7e:7f:27:22:7b:02: 253 d1:9a:d5:22:2e:b7:4a:b7:59:0e:12:f7:7c:00:07: 254 f0:ce:00:37:3d:19:69:78:99:60:7f:da:0a:0b:0e: 255 c0:94:59:74:87:62:cd:9c:cd:2f:f6:6b:f2:e1:f4: 256 c2:90:b0:32:8b:41:b1:0c:9d:cc:5a:ab:74:d5:04: 257 6e:d4:ae:af:52:46:79:9e:9a:0b:9a:5a:3b:e8:9e: 258 2d:28:ef:6e:67:5a:2f:e3:e4:7e:80:b4:e6:58:a0: 259 51:a6:71:c8:f1:ad:a4:80:54:65:92:e2:bf:b4:5f: 260 7a:92:65 261 Exponent: 65537 (0x10001) 262 Challenge String: challenge 263 Signature Algorithm: sha256WithRSAEncryption 264 92:60:98:11:4c:0f:ed:80:aa:44:29:0f:fd:80:80:27:28:28: 265 d9:11:99:c0:fc:12:41:d0:63:ee:56:37:cd:3e:a2:06:96:7f: 266 95:5c:0d:4d:f2:70:fd:b9:e7:8c:7d:e4:43:cb:85:c9:6a:ad: 267 7f:71:6f:35:1e:9a:e5:28:36:24:7f:b0:fc:a1:c6:5d:0f:af: 268 b3:8f:b4:aa:ae:95:6e:90:bd:3f:98:09:cc:ab:6c:82:d1:d6: 269 31:3c:96:15:52:10:d9:13:fd:f2:fa:53:d2:78:34:f7:7b:a8: 270 60:74:38:58:93:bf:db:40:4f:58:6e:cf:3b:97:83:1e:bb:e9: 271 3f:18:e6:66:fd:5d:59:34:0b:a0:82:18:4a:03:c5:22:88:da: 272 7d:ff:9d:b9:1d:cb:25:e5:ab:5b:85:a6:1c:15:09:71:01:52: 273 fa:e7:74:3f:32:de:f2:9d:f2:b8:6d:1b:2b:f3:f1:c4:e0:da: 274 af:e6:1e:64:87:95:dc:30:99:f9:2c:69:13:70:87:d9:b1:38: 275 a7:ab:2d:44:39:a4:53:3a:f0:73:83:3a:72:47:16:cf:c3:db: 276 a1:90:97:02:0d:7d:5a:ab:56:72:3e:a0:20:3f:54:51:73:fd: 277 03:b8:9a:29:d3:ef:3b:83:48:66:bf:70:57:62:3d:68:f7:77: 278 ff:c6:cf:4d:a9:a5:42:07:93:c4:55:2a:b7:46:81:37:ff:79: 279 f4:26:6c:fd:b3:2c:47:da:01:f4:d4:95:28:d5:96:25:43:ab: 280 0e:52:44:6e:90:25:8a:ef:cf:cd:29:7d:97:33:d7:70:58:de: 281 99:0d:e6:59:c0:72:e0:3c:2d:de:46:6f:f6:15:7e:22:64:89: 282 e7:ef:32:df:6d:ef:9d:e9:7b:d6:31:bf:c8:94:e8:f2:9f:40: 283 ef:14:6e:21:9b:3d:f1:03:3f:96:d0:d4:42:4f:5f:4a:dd:9a: 284 f5:fb:4f:ce:61:c1:1e:cb:5c:2e:62:50:1b:36:c5:d6:a1:4d: 285 f0:e0:a1:94:d9:ff:5d:9f:4a:83:70:91:d8:26:61:44:66:cb: 287 f7:c0:10:e9:d5:1c:89:f9:1a:3f:cb:2a:ef:22:8b:65:0e:cd: 288 69:2d:6c:09:f3:e1:fd:f4:31:eb:85:79:a0:71:e6:1f:6f:7b: 289 f9:c4:2d:09:ef:b0:f8:99:80:80:c5:74:a6:1d:5d:bf:32:25: 290 14:e0:83:d6:a1:61:d3:e1:10:2f:ee:d5:12:09:17:1b:38:b1: 291 19:91:7d:9c:18:ee:a0:13:b2:c2:e1:9c:bf:59:0e:d0:ee:b9: 292 9c:49:7e:df:ac:9f:9b:30:a6:27:a9:4a:27:a4:1a:fc:36:d1: 293 fb:0f:ea:d4:43:e2:7b:b4 295 5. IANA Considerations 297 IANA is asked to assign the value "spkac" below { iso(1) identified- 298 organization(3) dod(6) internet(1) security(5) mechanisms(5) } as per 299 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 300 numbers-26 for the identifier of the ASN.1 SPKAC schema, and to add 301 this to the ASN.1 definition in this specification. 303 All drafts are required to have an IANA considerations section (see 304 Guidelines for Writing an IANA Considerations Section in RFCs 305 [RFC5226] for a guide). If the draft does not require IANA to do 306 anything, the section contains an explicit statement that this is the 307 case (as above). If there are no requirements for IANA, the section 308 will be removed during conversion into an RFC by the RFC Editor. 310 6. Security Considerations 312 The aim of SPKAC is that no adversary can convince a certificate 313 authority to sign a certificate using the public key other than that 314 intended. An adversary is any entity other than the end entity and 315 the certificate authority attempting to establish proof-of- 316 possession. 318 6.1. Use of the MD5 Message-Digest Algorithm 320 Historically the formal definition of the HTML keygen tag specified 321 that the MD5 message-digest algorithm be used within SPKAC requests. 323 As defined in Updated Security Considerations for the MD5 324 Message-Digest and the HMAC-MD5 Algorithms [RFC6151] MD5 must not be 325 used for digital signatures. 327 New protocols using the SPKAC protocol MUST NOT mandate the use of a 328 fixed message-digest algorithm, and existing protocols using the 329 SPKAC protocol SHOULD be updated to ensure the message-digest used is 330 not fixed to a given digest. 332 6.2. Clear Text Challenge and Public Key 334 Given that both the Challenge and the Public Key are encoded within 335 the SPKAC message in clear text, to ensure privacy of the data in 336 transit additional steps SHOULD be taken to ensure that SPKAC message 337 is delivered over a secure transport, such as TLS [RFC8446]. 339 6.3. UI/UX Denial of Service Design Issues 341 When the generation of an SPKAC message is triggered by a remote 342 entity, such as a certificate authority triggering the generation of 343 an SPKAC message in a browser as part of a certificate request, the 344 user interfaces in the client (browser) should take care to not allow 345 (rogue) webpages or javascript to generate a very large number of 346 keygen requests; as this is not only somewhat resource intensive; but 347 may also deplete cryptographic quality random generator pools 348 (historically a concern). This is especially important as most 349 implementations will generally keep the cryptographic code and 350 (private) key storage outside the sandbox in which the DOM and 351 Javascript is handled. 353 Likewise - clients (browsers) should be particularly careful when 354 handling solicited (and unsolicited and maliciously repeated/high- 355 volume) responses to a SPKAC submission when storing certificates and 356 recombining certificates with keys in the key store. Especially as 357 (historically) it was common for such request to be handled 358 asynchronously; with the user receiving an email after, for example 359 human approval, to pick up the signed certificate at a certain URL. 361 Clients SHOULD make a request to the user for consent for the client 362 to generate the SPKAC message in a clear and easy to understand 363 manner, with cancel being the default choice should the user not 364 understand the request. 366 7. References 368 7.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 376 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 377 2006, . 379 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 380 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 381 . 383 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 384 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 385 DOI 10.17487/RFC5911, June 2010, 386 . 388 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 389 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 390 DOI 10.17487/RFC5912, June 2010, 391 . 393 [RFC6151] Turner, S., "Updated Security Considerations for the MD5 394 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, 395 March 2011, . 397 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 398 "PKCS #1: RSA Cryptography Specifications Version 2.2", 399 RFC 8017, DOI 10.17487/RFC8017, November 2016, 400 . 402 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 403 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 404 . 406 [W3C.REC-html5-20141028] 407 Hickson, I., Berjon, R., Faulkner, S., Leithead, T., 408 Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", World 409 Wide Web Consortium Recommendation REC-html5-20141028, 28 410 October 2014, 411 . 413 [X.690] authSurName, authInitials., "Information technology - 414 ASN.1 encoding rules: Specification of Basic Encoding 415 Rules (BER), Canonical Encoding Rules (CER) and 416 Distinguished Encoding Rules (DER).", ITU-T Recommendation 417 X.690 (2002) ISO/IEC 8825-1:2002, 2002. 419 7.2. Informative References 421 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 422 IANA Considerations Section in RFCs", RFC 5226, 423 DOI 10.17487/RFC5226, May 2008, 424 . 426 Authors' Addresses 428 Graham Leggett (editor) 429 Pepperpot Media 430 London 431 United Kingdom 433 Email: minfrin@sharp.fm 435 Dirk-Willem van Gulik 436 WebWeaving Internet Engineering 437 Leiden 438 Netherlands 440 Email: dirkx@webweaving.org