idnits 2.17.1 draft-hallambaker-prismproof-key-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 28 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...tificate issuers SHOULD use Strong Key...' RFC 2119 keyword, line 186: '...al dash (-) characters MAY be added to...' RFC 2119 keyword, line 187: '... readability and MUST be ignored by co...' RFC 2119 keyword, line 257: '...t to the address MUST be encrypted und...' RFC 2119 keyword, line 262: '... sent to the address MUST be encrypted...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 221, but not defined == Unused Reference: 'RFC5280' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: 'RFC2986' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'RFC3501' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC5034' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-prismproof-trust' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'RFC4880' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'I-D.moriarty-pkcs12v1-1' is defined on line 1051, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) == Outdated reference: A later version (-01) exists of draft-hallambaker-prismproof-trust-00 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 5208 (Obsoleted by RFC 5958) ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-05) exists of draft-moriarty-pkcs12v1-1-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 17, 2013 4 Expires: April 20, 2014 6 PRISM_Proof Email Key Generation and Publication 7 draft-hallambaker-prismproof-key-00 9 Abstract 11 This document describes previous efforts and their deployment legacy 12 and the requirements for a successful email security infrastructure. 13 A gap analysis is performed and the tasks divided into problems that 14 are generally considered solved albeit possibly requiring improved 15 execution and problems that may be regarded as research. 17 This division of the problem space into 'execution' and 'research' 18 portions allows different groups of developers to address each 19 independently and avoid unnecessary duplication of effort. A testbed 20 for development and early adopter deployment that achieves this 21 separation is described. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Legacy Infrastructure . . . . . . . . . . . . . . . . . . 3 57 2. Key Generation and Identification . . . . . . . . . . . . . . 3 58 2.1. Strong Key Identifier . . . . . . . . . . . . . . . . . . 3 59 2.1.1. Strong Email Addresses . . . . . . . . . . . . . . . 4 60 2.2. Private Key Backup and Controlled Recovery . . . . . . . 6 61 2.2.1. Encrypted Private Key . . . . . . . . . . . . . . . 7 62 2.2.2. Key Splitting . . . . . . . . . . . . . . . . . . . 8 63 2.3. Private Key Example . . . . . . . . . . . . . . . . . . . 8 64 2.3.1. Key Identifier . . . . . . . . . . . . . . . . . . . 8 65 2.3.2. Private Key Backup . . . . . . . . . . . . . . . . . 9 66 3. Public Key Infrastructure . . . . . . . . . . . . . . . . . . 11 67 3.1. Certificate Signing Request. . . . . . . . . . . . . . . 11 68 3.2. Self-Signed Certificate. . . . . . . . . . . . . . . . . 11 69 3.3. Peer Endorsement . . . . . . . . . . . . . . . . . . . . 11 70 4. Publication Service . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Initial Key Publication . . . . . . . . . . . . . . . . . 14 72 5. Registration Example . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. Enabling a new Device . . . . . . . . . . . . . . . . . . 17 74 6. Recovery Example . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 18 76 7. Revocation Example . . . . . . . . . . . . . . . . . . . . . . 18 77 7.1. Key Endorsement . . . . . . . . . . . . . . . . . . . . . 18 78 8. Endorsement Example . . . . . . . . . . . . . . . . . . . . . 18 79 9. OmniAssertBroker . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Assert . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.1.1. Structure: Service . . . . . . . . . . . . . . . . . 19 82 9.1.2. Structure: EncryptedKey . . . . . . . . . . . . . . 20 83 9.1.3. Message: AssertRequest . . . . . . . . . . . . . . . 20 84 9.1.4. Message: AssertResponse . . . . . . . . . . . . . . 21 85 9.2. Recover . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 9.2.1. Message: RecoverRequest . . . . . . . . . . . . . . 21 87 9.2.2. Message: RecoverResponse . . . . . . . . . . . . . . 21 88 9.3. Revoke . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.3.1. Message: RevokeRequest . . . . . . . . . . . . . . . 22 90 9.3.2. Message: RevokeResponse . . . . . . . . . . . . . . 22 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 95 12.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Problem Statement 100 Generating a public keypair and registering it for use should be the 101 only occasion on which a user is required to think about their 102 cryptographic security. Nor should the user be required to think too 103 much in this circumstance either. 105 To enable others to send encrypted email to them, a user must at 106 minimum generate at least one public keypair and make the public key 107 portion available to the intended communit of potential senders. The 108 precise means by which this is achieved may be considered a hard 109 research problem. Accordingly this specification anticipates such 110 processing being performed 'in the cloud' (i.e. by magic) and 111 describes a Web Service interface that may be used to 113 1.1. Legacy Infrastructure 115 Twenty years of effort attempting to deploy secure email has left a 116 considerable legacy of deployed code. While this deployed code base 117 is not ideally suited to the task (or the problem would be solved 118 already) it is generally better to support use of such deployed 119 resources where they exist rather than attempt to build everything 120 from scratch. 122 One significant design consequence that flows from this approach is 123 to adopt ASN.1 encoding for cryptagraphic data objects, including the 124 Key Endorsement object described in this document. While there are 125 many better choices of data encoding and remarkably few that are 126 worse, most cryptographic toolkits provide support for parsing 127 X.509v3 certificates and generating Certificate Signing Requests and 128 many provide comprehensive support for a wide range of ASN.1 encoded 129 objects. 131 2. Key Generation and Identification 133 2.1. Strong Key Identifier 135 A Strong Key Identifier is an identifier that identifies a unique 136 public key formed using a strong Message digest function over the 137 public key parameter values. 139 This definition of Key Identifiers is considerably more restrictive 140 than the PKIX definition which allows an issuer to use any unique 141 string for the subjectKeyIdentifier and authorityKeyIdentifier 142 extensions. 144 Compliant certificate issuers SHOULD use Strong Key Identifiers as 145 specified in this document for PKIX Key Identifiers. 147 A strong Key Identifier takes one of the two following forms: 149 If the length of the Key Identifier is exactly 20 octets. 150 The Key Identifier is an OpenPGP v4 Key fingerprint calculated 151 as specified in [!RFC4880] 153 Otherwise 154 The first byte specifies the digest algorithm and the following 155 bytes the digest value calculated over the DER encoded 156 SubjectPublicKeyInfo. 158 The following algorithm values are assigned in this document: 160 0 161 SHA-2-512 truncated to 128 bits. 163 1 164 SHA-2-512 truncated to 224 bits. 166 2 167 SHA-2-512 truncated to 256 bits. 169 3 170 SHA-2-512 without truncation 172 128-255 173 Reserved for use in a future multi-byte algorithm identifier 174 scheme. 176 To prevent a downgrade attack in which an attacker truncates a longer 177 Key Identifier, the input to the message digest function is prepared 178 as follows: 180 Let V be the algorithm identifier value and D be the DER encoded 181 SubjectPublicKeyInfo and + stand for simple concatenation. 183 Key Identifier = H (V + D) 185 If it is necessary to present a Key Identifier to an end user, Base32 186 encoding is used. Additional dash (-) characters MAY be added to 187 improve readability and MUST be ignored by compliant applications. 189 2.1.1. Strong Email Addresses 191 To establish encrypted communications it is necessary to know a 192 public key for the recipient and the recipient's security policy. The 193 fact that a recipient is capable of receiving encrypted email does 194 not mean that they are capable of receiving encrypted email on every 195 device they use or that they are willing to accept encrypted email 196 from every sender. 198 A similar problem was faced when using Transport Layer Security 199 [RFC5246] with HTTP [RFC2616]. By default, Web requests are sent 200 without use of security. To force use of TLS, the URI method https is 201 used in place of http. The security policy is encoded in the URI. 203 Strong email addresses allow an email sender to encode the security 204 policy in an RFC822 [RFC2822] compliant email address. RFC822 defines 205 the 'user name' portion of an email address as follows: 207 addr-spec = local-part "@" domain 208 local-part = dot-atom / quoted-string / obs-local-part 209 atext = ALPHA / DIGIT / 210 "!" / "#" / 211 "$" / "%" / 212 "&" / "'" / 213 "*" / "+" / 214 "-" / "/" / 215 "=" / "?" / 216 "^" / "_" / 217 "`" / "{" / 218 "|" / "}" / 219 "~" 220 atom = [CFWS] 1*atext [CFWS] 221 dot-atom = [CFWS] dot-atom-text [CFWS] 223 In a Strong Email Address, the character '?' is reserved. Although 224 this is a legitimate account name in some operating systems, use is 225 prohibited in current editions of Windows and most UNIX based 226 operating systems. 228 The address syntax is modified as follows: 230 addr-spec = local-part "@" domain 231 local-part = dot-atom / quoted-string / 232 obs-local-part / strong-local 233 atext = ALPHA / DIGIT / 234 "!" / "#" / 235 "$" / "%" / 236 "&" / "'" / 237 "*" / "+" / 238 "-" / "/" / 239 "=" / 240 "^" / "_" / 241 "`" / "{" / 242 "|" / "}" / 243 "~" 244 strong-local = indirect-key / direct-key / nokey 246 ktext = ALPHA / DIGIT / "-" 247 key-identifier = 1*ktext 249 indirect-key = key-identifier "??" dot-atom 250 direct-key = key-identifier "?" dot-atom 251 nokey = "?" dot-atom 253 Addresses of the form indirect-key, direct-key and nokey are 254 interpreted as follows: 256 nokey 257 Messages sent to the address MUST be encrypted under an 258 encryption key that the sender determines to be trustworthy. 260 direct-key 261 If the public key specified by the Key Identifier is an 262 encryption key, messages sent to the address MUST be encrypted 263 under the specified key. Otherwise messages sent to the address 264 MUST be encrypted under an encryption key that has a direct key 265 endorsement under the specified key. 267 indirect-key 268 Messages sent to the address MUST be encrypted under an 269 encryption key that has a key endorsement under the specified 270 key. 272 2.2. Private Key Backup and Controlled Recovery 274 A frequently overlooked hazzard of using encryption is the risk of 275 data loss should the private key be lost or otherwise become 276 unavailable. Another practical difficulty that must be faced is the 277 need to enable encrypted email to be read on more than one device. 278 Once published, a strong email identifier effectively becomes a 279 personal root of trust, the value of which may increase over time. 281 Each of these use cases requires some form of private key backup and 282 recovery mechanism. While such mechanisms have traditionally been 283 considered to be an implementation choice that is outside the scope 284 of a protocol specification, to do so incurs a substantial risk of a 285 large number of bad implementation choices. In particular the need to 286 enable receipt of email on multiple devices requires a standards 287 based approach or else applications provided by different vendors 288 will not be able to exchange keys. 290 While a Key Escrow capability provides a Key Backup capability, the 291 reverse is not true. A Key Escrow system is generally understood to 292 support recovery of the private key without notice to the private key 293 holder while a Key Backup system need not meet this requirement. 295 A publication service MAY support Key Backup and Recovery. A user MAY 296 choose to use the Key Backup and Recovery function supported by a 297 Publication service. 299 If Key Backup is used, the key management client encrypts the private 300 key under a strong symmetric key and sends the encrypted data to the 301 publication service. The information necessary to recover the private 302 key is presented to the user in a compact form that MAY be written 303 down and stored without risk of hardware failure rendering the key 304 inaccessible. 306 2.2.1. Encrypted Private Key 308 Private Keys are encrypted using the PKCS#8 format as specified in 309 [RFC5208]. 311 This specification is prefered to the PKCS#12 [I-D.moriarty-pkcs12v1- 312 1] format as the latter is essentially a wrapper for multiple PKCS#8 313 keys and associated certificates that can be generated by a 314 publication service if necessary. 316 Key management tools MUST support the use of AES-256 to encrypt 317 private keys. AES is prefered over AES-128 for the greater number of 318 encryption cycles rather than the increased brute force work factor. 319 Applications MAY use encryption keys with lengths less than 256 bits 320 provided that the keys have a length of at least 128 bits. 322 If the key size used is shorter than the key size required by the 323 encryption algorithm, the HKDF-Expand function described in [RFC5869] 324 is used to expand the truncated key to provide the necessary number 325 of bits. 327 Keys are presented in BASE32 encoding [RFC4648] with optional 328 separators '-' to improve readability. Applications MUST ignore 329 separators when decoding the keys. 331 2.2.2. Key Splitting 333 Key Management tools MAY support the use of a key splitting scheme to 334 allow greater control over key recovery. For example, the user might 335 split their key into three parts with a requirement that two parts 336 are necessary to reconstruct the key. 338 At this point the author has a paper by Rober Blakely Snr on an out- 339 of-patent key splitting scheme but insufficient time to read the 340 paper let alone write and implement the specification. If anyone is 341 looking for something to do, that would be useful. 343 2.3. Private Key Example 345 Alice uses a key generation tool to generate a public keypair. The 346 public parameters in hexadecimal are: 348 Modulus : 349 c1 66 de 02 62 35 3f af 7a 22 11 66 62 5a 1b 8d 350 3b 85 14 65 32 5d 6c e0 b5 db 09 e0 fc e4 16 34 351 96 ac 5b 76 01 96 e4 37 d5 8b db 52 a7 71 68 1c 352 86 1a 61 58 a7 0a 91 14 f2 d9 cd 4a 6b a5 e2 b3 353 94 c9 0b f2 7b ff 3b 6e a8 7b bf ca 27 0e b2 28 354 b0 d5 4a 1b 59 9a 8b 40 4e 80 3b dd 79 57 25 52 355 7a 70 ba 22 02 45 7b 4c e8 95 69 34 79 77 86 5f 356 09 36 30 18 1b 77 be c5 dc d3 ea db 1b 0a a0 8f 357 Exponent : 358 01 00 01 360 2.3.1. Key Identifier 362 KeyIdentifier: ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA 364 alice@example.com 365 Send email to Alice using encryption if and only if an 366 encryption key for Alice can be found and Alice has published 367 the email encryption policy 'encryption preferred' or stronger. 369 ?alice@example.com 370 Send email to Alice using encryption if and only if an 371 encryption key for Alice can be found, otherwise report an 372 error. 374 ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO- 375 VAA?alice@example.com 376 Send email to Alice using encryption if and only if an 377 encryption key for Alice can be found that is directly endorsed 378 under the specified key, otherwise report an error. 380 ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO- 381 VAA??alice@example.com 382 Send email to Alice using encryption if and only if an 383 encryption key for Alice can be found that is (directly or 384 indierectly) endorsed under the specified key, otherwise report 385 an error. 387 2.3.2. Private Key Backup 389 The private key component of Alice's key is as follows: 391 P : 392 f3 85 24 7b 95 3d a1 77 7c a4 4d a8 b8 00 3e 73 393 b2 9d 36 52 dc 64 21 e2 90 56 3c 51 d6 24 0c 20 394 77 1e d1 35 b4 c8 77 00 86 96 af 66 b0 5e 31 ff 395 15 ef 40 5e 00 21 54 18 fb dd f6 c2 bc 93 c2 1d 396 Q : 397 cb 50 32 f4 eb b5 74 80 b0 d1 f6 41 8c 90 9f 56 398 50 19 4e 64 be 93 f0 a2 bc 3c e9 e6 48 56 99 4e 399 4e 33 9c 77 31 92 45 a6 aa 35 39 7c f8 aa f3 35 400 85 05 09 78 8a 9f 4d 90 e3 36 61 84 ec 39 2d 9b 401 DP : 402 ca fa 35 58 95 22 d3 cd 66 a5 04 de 16 d0 8d 3d 403 9e a9 8f b8 2d 5f 81 26 f9 ac 07 87 26 f8 d0 ea 404 d6 9f 67 3e 5e bb a1 05 5d 29 88 76 0d 97 d6 10 405 8a d5 eb 4e ee c8 d8 f2 22 2d f7 1a 86 58 9a b9 406 DQ : 407 73 74 37 7b 9d de 8d 2a 07 3f 33 f8 45 3a 5b 41 408 48 7b 16 69 5f 4f e3 76 86 2e 91 24 94 2f 99 1f 409 3e 89 50 70 df 55 90 f7 f3 f0 05 95 52 20 c1 bb 410 c2 ad f9 92 da 25 5c 86 ca 80 37 20 a4 84 53 c1 411 InverseQ : 412 c1 b9 4b bf ee 41 77 b9 dc 0c cd 97 c0 96 77 22 413 0d e0 ed b2 3f 02 25 63 c8 0d 86 d8 5c 44 df 4d 414 d5 d7 3e 78 4a 5f 3d cb 76 5a 9b a8 1a 68 8e 47 415 9c 47 f9 8f 81 8d 6b 99 ab 74 56 88 4f ac c3 88 417 The private key is encrypted under a randomly assigned symmetric key 418 using PKCS8 encoding. 420 30 82 02 88 30 02 05 00 04 82 02 80 f3 fa 63 b9 421 1c d3 60 54 2f 75 ca 99 fe 42 1f 21 0d 2c f9 bd 422 4a 72 e4 ba da 09 91 f3 96 b7 b8 4a b6 78 da bc 423 92 55 ce c0 77 7c 75 96 86 05 cf 21 1b 23 a6 c6 424 12 fc e6 2c a5 36 7f 14 b3 bc 53 70 8a 8e fe 7f 425 99 d6 1d da 00 5f 5b 43 b2 cf 2d eb 0f 23 9c ce 426 0b bd 9c 81 29 b9 b8 7d 78 35 55 f7 45 5e 7b e0 427 d6 ef 9b bd 79 51 be 6d 88 f7 63 bb ef c8 b9 5b 428 90 c2 e9 a1 b5 d2 7b dd 69 95 3b 55 3a 79 8f 70 429 f4 26 38 4e 40 50 43 14 8c 57 65 7c cc 37 6a e2 430 4d 2f 51 fe 06 05 3b 7c 60 47 58 01 ef c6 f1 ae 431 4c 3c 28 8c c5 f0 0b f6 dd 8f ff 5d 22 a8 b6 5e 432 1b 94 29 ad f5 63 2e b8 60 ec 96 c8 63 df 2b 50 433 8b 27 a9 da ff 4a f8 b1 7d 6f 30 4c 9b 3d f6 65 434 a0 3e 24 6d 6f 2e d5 37 a4 52 ef 5a ef 11 51 84 435 e3 7e d2 19 7e 86 34 22 c5 78 5e 9e 6f 40 10 76 436 b3 cd 34 dd ea 3b 0e fc f3 38 1e e6 a3 32 54 a1 437 1a 7e 51 8d 0c 99 2e e7 20 06 21 5e b9 f8 87 19 438 f1 cd 82 00 6f 72 fb b9 a3 85 21 fb ac 80 2b aa 439 3a 47 b0 5d 03 74 77 08 70 de 64 25 a3 f5 bb 97 440 a3 08 ff 29 db 17 7b fa f8 80 c0 4e 90 5d 9a 15 441 04 60 73 f6 47 ff 82 6b 16 ce 19 a2 a0 1e a1 a3 442 a0 b0 2a fa 5b 51 0b 0c ab 92 53 fe 1e 1d af d9 443 78 9f 70 26 a6 32 80 d1 ef 6d 67 2a 48 b1 4b 3d 444 76 cf bc 8e 48 0c b0 9d da cf 4c b2 be aa d3 5f 445 ed 91 36 76 ef 5e ef 95 9c fd 4f 72 46 1d cf d2 446 15 4c 1a 93 9f 52 84 ce a5 c8 17 ff bc 0e 70 83 447 fc d3 c9 98 b6 0d f0 a8 72 8d 2d d4 49 6d 9d 79 448 35 c7 48 36 b1 49 95 f0 02 77 52 7a 50 13 74 80 449 7b 9d 1b bf cf f2 1e 99 6e 92 8f 8b b2 d8 35 6c 450 c9 2f 5d 3d da 4c 53 49 03 d6 63 56 7b d6 80 5d 451 69 b6 8d 9b fd 50 f4 c8 5e 9a 3c 91 26 b7 0a 62 452 d3 a7 2d 99 49 b2 1b 0f 74 71 62 ce 41 8a 2c dd 453 8a b4 97 38 dc be b8 6f b6 ba 29 e4 73 2d c0 ee 454 23 d1 2b 97 eb 7c 8d 42 16 33 3d 93 84 31 59 2f 455 f7 26 78 f2 3f 9a af ff 26 81 da 34 a6 74 bf 35 456 a9 c5 4d 6a 9d 48 d8 4b 00 a5 56 c2 46 e2 ce 65 457 f8 86 22 75 07 32 df 69 2c e2 74 09 54 4a 1e 38 458 62 56 6e 8e be c4 23 78 c1 f4 ea 20 96 a7 ac 89 459 54 6f 2d 0f 73 53 3b 66 7a 61 69 e7 6a d0 00 00 460 00 00 00 00 00 00 00 00 00 00 00 00 462 The cipher (specified in the PKCS8 object) is AES-256. The password 463 value in Base-32 encoding is: 465 Passcode: H2AL6A-ESJYAE-JABNDMA-HAAANDG; 467 1/3: CFAHVA-FMUWAN-PAHXIZA-BAAH2FE 468 2/3: PCAP7A-BEBNAH-LACDFJA-OAAHZXE 469 3/3: DBABPA-EHTBAD-CAGVAZA-MIAGPXE 471 3. Public Key Infrastructure 473 The precise means by which a public key is validated by a relying 474 party is outside the scope of this specification. Keys MAY be 475 validated by a traditional Certificate Authority or through peer to 476 peer endorsement or any combination of the two. 478 In order to maximize the flexibility for the trust infrastructre 479 designers, two syntaxes for presenting public keys for use are 480 supported. Key Management tools SHOULD support both: 482 A Certificate Signing Request 483 May be presented to a CA or other signer. 485 A self signed certificate 486 Presents the public key in a form that many Internet 487 applications accept directly. 489 3.1. Certificate Signing Request. 491 Certificate Signing Requests SHOULD conform to the following profile: 493 * The Key Identifier MUST be specified and MUST be a strong key 494 identifier 496 * [[Prohibit various PKIX lunacies] 498 3.2. Self-Signed Certificate. 500 Self Signed Certificates SHOULD conform to the following profile: 502 * The Key Identifier MUST be specified and MUST be a strong key 503 identifier 505 * [[Prohibit various PKIX lunacies] 507 3.3. Peer Endorsement 509 Traditionally PKIX only permits use of Certification Authority 510 provided trust assertions while OpenPGP only permits use of peer 511 endorsement through key signing. PPE supports the use of a 512 combination of both approaches for reasons described in [I- 513 D.hallambaker-prismproof-trust] 514 To perform peer endorsement, the following data structure is used: 516 Class Endorsement 517 TBSEndorsement TBSEndorsement 518 SignatureAlgorithm AlgorithmIdentifier 519 Signature Bits 521 Class TBSEndorsement 522 Version Integer 523 Issued Time 524 IssuerKeyIdentifier Octets 525 SubjectKeyIdentifier Octets 526 Subject List Name 527 SubjectAltName List SubjectAltName 528 Extensions List Extension 530 Class AlgorithmIdentifier 531 Algorithm OIDRef 532 Parameters Any 534 Class Name 535 Member Set AttributeTypeValue 537 Class AttributeTypeValue 538 Type OIDRef 539 Value AnyString 541 Object SubjectAltName id_ce_subjectAltName 542 Names List GeneralName 544 Class GeneralName 545 Value Choice 546 RFC822Name IA5String 547 Code 1 548 Implicit 549 DNSName IA5String 550 Code 2 551 Implicit 553 Class Extension 554 ObjectIdentifier OIDRef 555 Critical Boolean 556 Default "false" 557 Optional 558 Data Octets 560 [[Note that although my tool generates ASN.1 encoding this is for 561 purely pragmatic reasons of providing consistency. It is not meant to 562 in any shape or fashion stand for an endorsement of this crackpot 563 technology.] 564 A new structure is introduced to support Key Endorsement rather than 565 attempting to re-use the X.509v3 Certificate format in recognition of 566 key endorsement having distinctly different semantics from issue of 567 PKIX certificates. PKIX certificates are either end entity 568 certificates or certificate signing certificates. A PKIX certificate 569 is expressly prohibited from being used for both purposes. In the 570 PKIX model, finding a certificate chain to a trusted anchor is 571 necessary and sufficient to establish the trustworthiness of an end 572 entity certificate. In the Key Endorsement model the reliance on a 573 single key endorsement MAY be qualified by the age of the 574 endorsement, the circumstances of issue, the number of independent 575 trust paths from the relying party to the subject and the lengths of 576 each path. 578 Most of the fields in the TBSEndorsement structure have the same 579 semantics as in PKIX with the exception of the Validity interval 580 which is replaced by the time of issue. 582 The precise mechanism by which endorsement is used requires further 583 development. At minimum, the endorsement mechanism should allow the 584 following forms of endorsement to be differentiated: 586 Direct Endorsement 587 A endorsement of a user's key identifier by another key held by 588 the same user. This form of endorsement allows a user to 589 establish a personal master key that is only used for the 590 purpose of endorsing keys for specific uses (email encryption, 591 email signature, endorsement, etc.) 593 Peer Endorsement 594 A user endorses the key identifier of another user (the 595 subject) and possibly other aspects of the subject's identity 596 such as their name, likeness etc. Such an endorsement SHOULD 597 specify the basis for the endorsement (in person, remote, 598 recent acquaintance, verification of government documents, 599 childhood friend, etc.) 601 Group Endorsement 602 One of the use practices that has emerged from attempts to 603 employ PGP is the 'key party' in which groups of users perform 604 mutual keysigning. 606 Withdrawing an Endorsement 607 In certain circumstances, it MAY be necessary to withdraw an 608 endorsement. The reason for withdrawing the endorsement SHOULD 609 be specified in the UnEndorsement notice and MAY include, 610 notification of the loss of the private key, the subject is 611 deceased, etc.) 613 4. Publication Service 615 The Publication Service is a JSON/REST Web Service layered over HTTP 616 transport. Although the publication service performs an important 617 service, it is not a service trusted by the user since the 618 publication service has no access to the user's private key (except 619 in encrypted form) and does not sign any data that is read by the 620 user. 622 The Publication Service is one of the two interfaces between the part 623 of the email message security problem that is well understood and the 624 part that is widely regarded to be 'research'. 626 Selection of the publication service MAY be left to individual user 627 choice or a domain name holder MAY specify that publication requests 628 be directed to a specific publication service. Users of a public 629 email service are likely to want to insist on their own choice of 630 publication service while a bank or government enterprise that has 631 deployed its own security infrastructure is likely to want to insist 632 that only credentials they approve are accepted for their site. 634 To allow researchers the widest possible lattitude in developing new 635 trust infrastructures, publication of three trust assertion formats 636 are supported together with support for key backup and recovery. 637 These assertion formats are: 639 Self Signed Certificate 640 A PKIX self signed certificate which MAY be used in conjunction 641 with an existing application that accepts public key 642 information in self signed certificate form. 644 Certificate Signing Request 645 A PKCS#10 Certificate Signing Request conforming to [!RFC2986]. 646 A publication interface MAY forward the Certificate Signing 647 request to a Certificate Authority for issue of a PKIX end 648 entity certificate. 650 Key Endorsement 651 A Key Endorsement in the format described in this document. 653 4.1. Initial Key Publication 655 The first time that the Publication Service is used is after the user 656 generates a new keypair. 658 For example, Alice registers the keypair generated in the previous 659 example with her chosen Publication Service. Her key management tool 660 makes an Assert request to the service with the following 661 information: 663 * The Strong Key Identifier 665 * The Encrypted Private Key 667 * A Self-Signed Certificate 669 * A Signed Certificate Signing Request 671 * Service information describing the email service parameters to 672 be used when sending messages using the corresponding email 673 account. [[Which really should be encrypted, shouldn't they?] 675 5. Registration Example 677 Request 679 { 680 "AssertRequest": { 681 "KeyIdentifier": " 682 AJqCYq5r2i7DXllBrhJHESWbLe2rw84cTsPr6qo", 683 "EncryptedKey": { 684 "EncryptedPrivateKey": " 685 MIICiDACBQAEggKA8_pjuRzTYFQvdcqZ_kIfIQ0s-b1KcuS62gmR85a3uEq2eNq8 686 klXOwHd8dZaGBc8hGyOmxhL85iylNn8Us7xTcIqO_n-Z1h3aAF9bQ7LPLesPI5zO 687 C72cgSm5uH14NVX3RV574Nbvm715Ub5tiPdju-_IuVuQwumhtdJ73WmVO1U6eY9w 688 9CY4TkBQQxSMV2V8zDdq4k0vUf4GBTt8YEdYAe_G8a5MPCiMxfAL9t2P_10iqLZe 689 G5QprfVjLrhg7JbIY98rUIsnqdr_SvixfW8wTJs99mWgPiRtby7VN6RS71rvEVGE 690 437SGX6GNCLFeF6eb0AQdrPNNN3qOw788zge5qMyVKEaflGNDJku5yAGIV65-IcZ 691 8c2CAG9y-7mjhSH7rIArqjpHsF0DdHcIcN5kJaP1u5ejCP8p2xd7-viAwE6QXZoV 692 BGBz9kf_gmsWzhmioB6ho6CwKvpbUQsMq5JT_h4dr9l4n3AmpjKA0e9tZypIsUs9 693 ds-8jkgMsJ3az0yyvqrTX-2RNnbvXu-VnP1PckYdz9IVTBqTn1KEzqXIF_-8DnCD 694 _NPJmLYN8KhyjS3USW2deTXHSDaxSZXwAndSelATdIB7nRu_z_IemW6Sj4uy2DVs 695 yS9dPdpMU0kD1mNWe9aAXWm2jZv9UPTIXpo8kSa3CmLTpy2ZSbIbD3RxYs5Biizd 696 irSXONy-uG-2uinkcy3A7iPRK5frfI1CFjM9k4QxWS_3JnjyP5qv_yaB2jSmdL81 697 qcVNap1I2EsApVbCRuLOZfiGInUHMt9pLOJ0CVRKHjhiVm6OvsQjeMH06iCWp6yJ 698 VG8tD3NTO2Z6YWnnatAAAAAAAAAAAAAAAAAAAA"}, 699 "Certificate": [" 700 MIICKjCCAZ4CAQICEQDPmUDPAObF9gNRAiPqkCswMAIFADAEMAIxADAeFw0xMzEw 701 MTYxMjAwMDFaFw0zMzEwMzEwNjA2MDJaMAQwAjEAMIGUMAIFAAOBjQAwgYkCgYEA 702 wWbeAmI1P696IhFmYlobjTuFFGUyXWzgtdsJ4PzkFjSWrFt2AZbkN9WL21KncWgc 703 hhphWKcKkRTy2c1Ka6Xis5TJC_J7_ztuqHu_yicOsiiw1UobWZqLQE6AO915VyVS 704 enC6IgJFe0zolWk0eXeGXwk2MBgbd77F3NPq2xsKoI8CAwEAAQUABQAwgbowKAMO 705 HVUCAQAEHwQdAJqCYq5r2i7DXllBrhJHESWbLe2rw84cTsPr6qowLwMjHVUCAQAE 706 JjAkBB0AmoJirmvaLsNeWUGuEkcRJZst7avDzhxOw-vqqgUAAgEAMCQDER1VAgEA 707 BBswGTAXMBUFABYRYWxpY2VAZXhhbXBsZS5jb20wDwMPHVUCAf8EBgMEAAcAgDAW 708 AyUdVQIBAAQNMAswCQgEAwcFBQEGKzAOAxMdVQIBAAQFMAMCAQAwAgUAA4GBAGMo 709 0Ky-ccYSHWqRLbd4JFns3UVgEbcbGUzm-H29DEJq1WUuihR03dfzeXQv9BY271o_ 710 Q_RsuFIbOYpEhpP2OG_5v6DdLOrvE6GsjydN7isLo0E6F-rxkVP6GfyMiDI5cr9z 711 1IR9b--DZUx_C8QK1c4JcASVANMc_Yt7_yn7kDkD"], 712 "CertificateRequest": [" 713 MIIBLTCBogIBADAEMAIxADCBlDACBQADgY0AMIGJAoGBAMFm3gJiNT-veiIRZmJa 714 G407hRRlMl1s4LXbCeD85BY0lqxbdgGW5DfVi9tSp3FoHIYaYVinCpEU8tnNSmul 715 4rOUyQvye_87bqh7v8onDrIosNVKG1mai0BOgDvdeVclUnpwuiICRXtM6JVpNHl3 716 hl8JNjAYG3e-xdzT6tsbCqCPAgMBAAEFADACBQADgYEABExEqqopLQXfVWZr5MJ0 717 digUmdcugrfykTnNMkLx3En8fVLMbrgBEu0Ndax_TqOk36_gjnyyjg2XGCI5BaTd 718 jHp13C8dsIdcfdePc3droSGLuPzMosZqzyN1qLhf5dEfXwp32gBwteXPV-YE9Nf3 719 rDEZ_vc32sK-09766Fbitz0"], 720 "Service": [{ 721 "Email": "alice@example.com", 722 "Name": "smtp.example.com", 723 "Protocol": "_smtp._tls", 724 "Port": 587, 725 "TLS": true}, 726 { 727 "Email": "alice@example.com", 728 "Name": "imap.example.com", 729 "Protocol": "_smtp._tls", 730 "Port": 993, 731 "TLS": true}]}} 733 Response 735 { 736 "AssertResponse": {}} 738 5.1. Enabling a new Device 740 Alice uses several different devices to read her email and she would 741 like to be able to read encrypted emails on all of them. This 742 requires that the private key be installed on each of the devices 743 that she might want to use. 745 Alice provides either the Key Recovery Passcode or a sufficient 746 number of Key Shares to reconstruct the passcode to the key 747 management tool running on each device. The device then requests 748 recovery of the private key and associated service information: 750 6. Recovery Example 752 Request 754 { 755 "RecoverRequest": { 756 "KeyIdentifier": " 757 AJqCYq5r2i7DXllBrhJHESWbLe2rw84cTsPr6qo"}} 759 Response 761 { 762 "RecoverResponse": {}} 764 Providing the service information with the private key allows the key 765 recovery tool to automate configuration of the user's email account 766 on the device if this has not been done already. 768 Using the key recovery mechanism to support key transport between 769 devices simplifies the initial coding task at the cost of a sub- 770 optimal user experience for the user with a large number of devices 771 in use and/or frequent key updates. 773 Future versions of the specification may adopt a different approach 774 to key recovery in which each device in which keys are to be 775 installed establishes a device specific keypair which is in turn used 776 to automate the key transport. A key concern in the design of such a 777 scheme being to prevent a weak random number generator on one device 778 causing the private key to be compromised. 780 6.1. Revocation 782 Should the private key be lost, the subject be deceased or some other 783 event occur that renders the key no longer servicable, a revocation 784 statement is generated and issued. Such revocation statements use the 785 Revoke request and the key endorsement message format: 787 7. Revocation Example 789 Request 791 { 792 "RevokeRequest": {}} 794 Response 796 { 797 "RevokeResponse": {}} 799 7.1. Key Endorsement 801 From time to time, Alice meets other PPE users and they endorse each 802 other's keys. The AssertRequest is used to submit one or more signed 803 key endorsements: 805 8. Endorsement Example 807 Request 809 { 810 "AssertRequest": { 811 "Endorsement": [" 812 MIH5MG8CAQAXDTEzMTAxNjA2MDYwM1oEHQCagmKua9ouw15ZQa4SRxElmy3tq8PO 813 HE7D6-qqBB0AGXoKrrHJ0-qMHfed6IOFC9Y_-V8bWp6Zmi_g3wUAMBkwFzAVMBMF 814 ABYPYm9iQGV4YW1wbGUuY29tBQAwAgUAA4GBAEPmx2IAjnlpR0z1V3K51HmjpYY3 815 dpJvsE0M41uAxPvhnnz-yCX5XYfa9MJzILag0eiVrVgTbE7CVH-ccRDgsr73sEri 816 LOc3vre32JWU2Cg1Y0s1sh1GMWJTj8DGPFLR-uOHCsFAxWK8XD6Y7hSlwZrh3EFu 817 SQfWoqzMtYkCY9wd"]}} 819 Response 821 { 822 "AssertResponse": {}} 824 A key endorsement MAY be submitted to the Publication Interface by 825 any party including the signer or the subject. 827 9. OmniAssertBroker 829 9.1. Assert 831 Register an assertion set. 833 The Assert transaction is used when a keypair is first created to 834 register the new Key Identifier, Self Signed Certificate and 835 Certificate Signing Request and to request revision of embedded 836 attributes such as the email security policy. 838 The Assert transaction is also used to request registration of Key 839 Endorsements. 841 9.1.1. Structure: Service 843 Email : 844 String [0..1] Principal Email address associated with the 845 account 847 OtherEmail : 848 String [0..Many] Additional Email addresses associated with the 849 account. 851 Name : 852 String [0..1] DNS Address of Service 854 Protocol : 855 String [0..1] SRV format protocol identification prefix. 857 Port : 858 Integer [0..1] IP Port number 860 TLS : 861 Boolean [0..1] If true, use of TLS is required 863 Security : 864 String [0..1] Security policy description 866 9.1.2. Structure: EncryptedKey 868 EncryptedPrivateKey : 869 Binary [1..1] PKCS#8 Encrypted Private Key as specified in 870 [!RFC5208]. 872 ReleaseCode : 873 Binary [0..1] Release Code value for authorizing private key 874 recovery requests. If specified the service MUST NOT release 875 the encrypted private key unless the requestor satisfies a 876 challenge-response request that establishes knowledge of the 877 Release Code. 879 9.1.3. Message: AssertRequest 881 Register an assertion set 883 At present only a single Key Identifier may be registered per request 884 and no provision is made to link related requests. This is likely to 885 become necessary when different keys are being used for key 886 endorsement, signature, encryption and master purposes. 888 KeyIdentifier : 889 Binary [1..1] Strong Key Identifier formed using a message 890 digest function over the DER encoded Public Key Info block. 892 EncryptedKey : 893 EncryptedKey [0..1] Encrypted Private Key and associated 894 attributes. 896 Certificate : 897 Binary [0..Many] PKIX Certificates to be registered, comply 898 with [!RFC5280] and additional profile constraints specified 899 here. 901 CertificateRequest : 902 Binary [0..Many] Certificate Request in [!RFC2986] format. 904 Endorsement : 905 Binary [0..Many] Key Endorsements as specified in this 906 document. 908 Service : 909 Service [0..Many] Service connection information for associated 910 services. For example, email IMAP [!RFC3501], POP3 [!RFC5034] 911 and SUBMIT [!RFC4409] accounts. 913 9.1.4. Message: AssertResponse 915 Response to an assertion registration request. 917 It may be useful to expand the response to allow the gateway to 918 provide information such as certificates issued in response to the 919 certification request but these will typically require some form of 920 validation and thus be returned asynchronously. 922 9.2. Recover 924 Recover a previously registered encrypted private key file from the 925 service 927 If the Key Identifier cannot be found or there is no release code 928 associated with the encrypted private key, the transaction is 929 complete after the first response. Otherwise the service returns the 930 status code 'ChallengeResponse' in response to the initial request 931 and the client MUST make a second request in which it establishes 932 proof of knowledge of the release code to complete the transaction. 934 9.2.1. Message: RecoverRequest 936 Request recovery of a previously registered encrypted private key. 938 KeyIdentifier : 939 Binary [1..1] Key Identifier of key pair for which recovery of 940 the private key is being requested. 942 Challenge : 943 Binary [0..1] Client challenge value for proof of knowledge of 944 the release code. 946 Answer : 947 Binary [0..1] Answer value for proof of knowledge of the 948 release code. 950 9.2.2. Message: RecoverResponse 952 Respond to a recovery request. 954 If the encrypted private key associated with the specified Key 955 Identifier has an associated 957 EncryptedPrivateKey : 958 Binary [0..1] PKCS#8 Encrypted Private Key as specified in 959 [!RFC5208]. 961 Challenge : 962 Binary [0..1] Server challenge value for proof of knowledge of 963 the release code. 965 Algorithm : 966 String [0..1] Digest algorithm for proof of knowledge of the 967 release code. 969 9.3. Revoke 971 Publish a revocation meta-assertion 973 9.3.1. Message: RevokeRequest 975 Regquest revocation of a previously registered key and all related 976 certificates and endorsements. 978 Note that whil key revocation necessarily entails revocation of all 979 the certificates and endorsement associated with the key, the reverse 980 is not the case. A user may revoke a certificate granting use of a 981 key for encrypted email without wishing to revoke a certificate for 982 the same key granting use for signed email. 984 KeyIdentifier : 985 Binary [1..1] Key Identifier of Key to be revoked. 987 Notice : 988 Binary [0..1] Signed Key Endorsement object with the 'revoke' 989 attribute specified. 991 9.3.2. Message: RevokeResponse 993 Response to revocation request. 995 10. Security Considerations 997 I am sure there are some. 999 11. Acknowledgments 1001 Thanks to the many people who have encouraged me in this work and in 1002 particular the members of the IETF PERPASS list and the Cryptography 1003 mailing list. Future versions of the draft will have a more complete 1004 list. 1006 12. References 1008 12.1. Normative References 1010 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 1011 R.,Polk, W., "Internet X.509 Public Key Infrastructure 1012 Certificate and Certificate Revocation List (CRL) 1013 Profile", RFC 5280, May 2008. 1015 [RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 1016 Syntax Specification Version 1.7", RFC 2986, November 1017 2000. 1019 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1020 4rev1", RFC 3501, March 2003. 1022 [RFC4409] Gellens, R.,Klensin, J., "Message Submission for Mail", 1023 RFC 4409, April 2006. 1025 [RFC5034] Siemborski, R.,Menon-Sen, A., "The Post Office Protocol 1026 (POP3) Simple Authentication and Security Layer (SASL) 1027 Authentication Mechanism", RFC 5034, July 2007. 1029 [I-D.hallambaker-prismproof-trust] Hallam-Baker, P, "PRISM Proof 1030 Trust Model", Internet-Draft draft-hallambaker-prismproof- 1031 trust-00, 16 October 2013. 1033 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1034 2001. 1036 [RFC4880] Callas, J.,Donnerhacke, L.,Finney, H.,Shaw, D.,Thayer, R., 1037 "OpenPGP Message Format", RFC 4880, November 2007. 1039 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 1040 Private-Key Information Syntax Specification Version 1.2", 1041 RFC 5208, May 2008. 1043 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1044 Encodings", RFC 4648, October 2006. 1046 [RFC5869] Krawczyk, H.,Eronen, P., "HMAC-based Extract-and-Expand 1047 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1049 12.2. Informative References 1051 [I-D.moriarty-pkcs12v1-1] Moriarty, K,Nystrom, M,Parkinson, S,Rusch, 1052 A,Scott, M, "PKCS 12 v1: Personal Information Exchange 1053 Syntax", Internet-Draft draft-moriarty-pkcs12v1-1-01, 25 1054 March 2013. 1056 [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, 1057 L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol 1058 -- HTTP/1.1", RFC 2616, June 1999. 1060 [RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security 1061 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1063 Author's Address 1065 Phillip Hallam-Baker 1066 Comodo Group Inc. 1068 philliph@comodo.com