idnits 2.17.1 draft-hallambaker-prismproof-key-01.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 147: '...tificate issuers SHOULD use Strong Key...' RFC 2119 keyword, line 189: '...al dash (-) characters MAY be added to...' RFC 2119 keyword, line 190: '... readability and MUST be ignored by co...' RFC 2119 keyword, line 259: '...t to the address MUST be encrypted und...' RFC 2119 keyword, line 264: '... 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 27, 2014) is 3468 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 224, but not defined == Unused Reference: 'RFC3501' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC2986' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC5034' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC4880' is defined on line 1062, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-prismproof-trust' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'I-D.moriarty-pkcs12v1-1' is defined on line 1077, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 5208 (Obsoleted by RFC 5958) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) == Outdated reference: A later version (-01) exists of draft-hallambaker-prismproof-trust-00 ** 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 27, 2014 4 Expires: April 30, 2015 6 PRISM_Proof Email Key Generation and Publication 7 draft-hallambaker-prismproof-key-01 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) 2014 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 . . . . . . . . . . . . . . . . . . . 7 63 2.3. Private Key Example . . . . . . . . . . . . . . . . . . . 7 64 2.3.1. Key Identifier . . . . . . . . . . . . . . . . . . . 8 65 2.3.2. Private Key Backup . . . . . . . . . . . . . . . . . 8 66 3. Public Key Infrastructure . . . . . . . . . . . . . . . . . . 10 67 3.1. Certificate Signing Request. . . . . . . . . . . . . . . 11 68 3.2. Self-Signed Certificate. . . . . . . . . . . . . . . . . 11 69 3.3. Peer Endorsement . . . . . . . . . . . . . . . . . . . . 11 70 4. Publication Service . . . . . . . . . . . . . . . . . . . . . 13 71 4.1. Initial Key Publication . . . . . . . . . . . . . . . . . 14 72 5. Registration Example . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. Enabling a new Device . . . . . . . . . . . . . . . . . . 16 74 6. Recovery Example . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17 76 7. Revocation Example . . . . . . . . . . . . . . . . . . . . . . 17 77 7.1. Key Endorsement . . . . . . . . . . . . . . . . . . . . . 17 78 8. Endorsement Example . . . . . . . . . . . . . . . . . . . . . 17 79 9. OmniAssertBroker . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. OmniAssertBroker Transactions . . . . . . . . . . . . . . 18 81 9.1.1. Assert . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.1.2. Recover . . . . . . . . . . . . . . . . . . . . . . 18 83 9.1.3. Revoke . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.2. OmniAssertBroker Messages . . . . . . . . . . . . . . . . 19 85 9.2.1. Message: AssertRequest . . . . . . . . . . . . . . . 19 86 9.2.2. Message: AssertResponse . . . . . . . . . . . . . . 19 87 9.2.3. Message: RecoverRequest . . . . . . . . . . . . . . 19 88 9.2.4. Message: RecoverResponse . . . . . . . . . . . . . . 20 89 9.2.5. Message: RevokeRequest . . . . . . . . . . . . . . . 20 90 9.2.6. Message: RevokeResponse . . . . . . . . . . . . . . 21 91 9.3. OmniAssertBroker Structures . . . . . . . . . . . . . . . 21 92 9.3.1. Structure: Service . . . . . . . . . . . . . . . . . 21 93 9.3.2. Structure: EncryptedKey . . . . . . . . . . . . . . 21 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 98 12.2. Informative References . . . . . . . . . . . . . . . . . 23 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Problem Statement 103 Generating a public keypair and registering it for use should be the 104 only occasion on which a user is required to think about their 105 cryptographic security. Nor should the user be required to think too 106 much in this circumstance either. 108 To enable others to send encrypted email to them, a user must at 109 minimum generate at least one public keypair and make the public key 110 portion available to the intended communit of potential senders. The 111 precise means by which this is achieved may be considered a hard 112 research problem. Accordingly this specification anticipates such 113 processing being performed 'in the cloud' (i.e. by magic) and 114 describes a Web Service interface that may be used to 116 1.1. Legacy Infrastructure 118 Twenty years of effort attempting to deploy secure email has left a 119 considerable legacy of deployed code. While this deployed code base 120 is not ideally suited to the task (or the problem would be solved 121 already) it is generally better to support use of such deployed 122 resources where they exist rather than attempt to build everything 123 from scratch. 125 One significant design consequence that flows from this approach is 126 to adopt ASN.1 encoding for cryptagraphic data objects, including the 127 Key Endorsement object described in this document. While there are 128 many better choices of data encoding and remarkably few that are 129 worse, most cryptographic toolkits provide support for parsing 130 X.509v3 certificates and generating Certificate Signing Requests and 131 many provide comprehensive support for a wide range of ASN.1 encoded 132 objects. 134 2. Key Generation and Identification 136 2.1. Strong Key Identifier 138 A Strong Key Identifier is an identifier that identifies a unique 139 public key formed using a strong Message digest function over the 140 public key parameter values. 142 This definition of Key Identifiers is considerably more restrictive 143 than the PKIX definition which allows an issuer to use any unique 144 string for the subjectKeyIdentifier and authorityKeyIdentifier 145 extensions. 147 Compliant certificate issuers SHOULD use Strong Key Identifiers as 148 specified in this document for PKIX Key Identifiers. 150 A strong Key Identifier takes one of the two following forms: 152 If the length of the Key Identifier is exactly 20 octets. 153 The Key Identifier is an OpenPGP v4 Key fingerprint calculated 154 as specified in [!RFC4880] 156 Otherwise 157 The first byte specifies the digest algorithm and the following 158 bytes the digest value calculated over the DER encoded 159 SubjectPublicKeyInfo. 161 The following algorithm values are assigned in this document: 163 0 164 SHA-2-512 truncated to 128 bits. 166 1 167 SHA-2-512 truncated to 224 bits. 169 2 170 SHA-2-512 truncated to 256 bits. 172 3 173 SHA-2-512 without truncation 175 128-255 176 Reserved for use in a future multi-byte algorithm identifier 177 scheme. 179 To prevent a downgrade attack in which an attacker truncates a longer 180 Key Identifier, the input to the message digest function is prepared 181 as follows: 183 Let V be the algorithm identifier value and D be the DER encoded 184 SubjectPublicKeyInfo and + stand for simple concatenation. 186 Key Identifier = H (V + D) 188 If it is necessary to present a Key Identifier to an end user, Base32 189 encoding is used. Additional dash (-) characters MAY be added to 190 improve readability and MUST be ignored by compliant applications. 192 2.1.1. Strong Email Addresses 194 To establish encrypted communications it is necessary to know a 195 public key for the recipient and the recipient's security policy. The 196 fact that a recipient is capable of receiving encrypted email does 197 not mean that they are capable of receiving encrypted email on every 198 device they use or that they are willing to accept encrypted email 199 from every sender. 201 A similar problem was faced when using Transport Layer Security 202 [RFC5246] with HTTP [RFC2616]. By default, Web requests are sent 203 without use of security. To force use of TLS, the URI method https is 204 used in place of http. The security policy is encoded in the URI. 206 Strong email addresses allow an email sender to encode the security 207 policy in an RFC822 [RFC2822] compliant email address. RFC822 defines 208 the 'user name' portion of an email address as follows: 210 addr-spec = local-part "@" domain 211 local-part = dot-atom / quoted-string / obs-local-part 212 atext = ALPHA / DIGIT / 213 "!" / "#" / 214 "$" / "%" / 215 "&" / "'" / 216 "*" / "+" / 217 "-" / "/" / 218 "=" / "?" / 219 "^" / "_" / 220 "`" / "{" / 221 "|" / "}" / 222 "~" 223 atom = [CFWS] 1*atext [CFWS] 224 dot-atom = [CFWS] dot-atom-text [CFWS] 226 In a Strong Email Address, the character '?' is reserved. Although 227 this is a legitimate account name in some operating systems, use is 228 prohibited in current editions of Windows and most UNIX based 229 operating systems. 231 The address syntax is modified as follows: 233 addr-spec = local-part "@" domain 234 local-part = dot-atom / quoted-string / 235 obs-local-part / strong-local 236 atext = ALPHA / DIGIT / 237 "!" / "#" / 238 "$" / "%" / 239 "&" / "'" / 240 "*" / "+" / 241 "-" / "/" / 242 "=" / 243 "^" / "_" / 244 "`" / "{" / 245 "|" / "}" / 246 "~" 247 strong-local = indirect-key / direct-key / nokey 249 ktext = ALPHA / DIGIT / "-" 250 key-identifier = 1*ktext 251 indirect-key = key-identifier "??" dot-atom 252 direct-key = key-identifier "?" dot-atom 253 nokey = "?" dot-atom 255 Addresses of the form indirect-key, direct-key and nokey are 256 interpreted as follows: 258 nokey 259 Messages sent to the address MUST be encrypted under an 260 encryption key that the sender determines to be trustworthy. 262 direct-key 263 If the public key specified by the Key Identifier is an 264 encryption key, messages sent to the address MUST be encrypted 265 under the specified key. Otherwise messages sent to the address 266 MUST be encrypted under an encryption key that has a direct key 267 endorsement under the specified key. 269 indirect-key 270 Messages sent to the address MUST be encrypted under an 271 encryption key that has a key endorsement under the specified 272 key. 274 2.2. Private Key Backup and Controlled Recovery 276 A frequently overlooked hazzard of using encryption is the risk of 277 data loss should the private key be lost or otherwise become 278 unavailable. Another practical difficulty that must be faced is the 279 need to enable encrypted email to be read on more than one device. 280 Once published, a strong email identifier effectively becomes a 281 personal root of trust, the value of which may increase over time. 283 Each of these use cases requires some form of private key backup and 284 recovery mechanism. While such mechanisms have traditionally been 285 considered to be an implementation choice that is outside the scope 286 of a protocol specification, to do so incurs a substantial risk of a 287 large number of bad implementation choices. In particular the need to 288 enable receipt of email on multiple devices requires a standards 289 based approach or else applications provided by different vendors 290 will not be able to exchange keys. 292 While a Key Escrow capability provides a Key Backup capability, the 293 reverse is not true. A Key Escrow system is generally understood to 294 support recovery of the private key without notice to the private key 295 holder while a Key Backup system need not meet this requirement. 297 A publication service MAY support Key Backup and Recovery. A user MAY 298 choose to use the Key Backup and Recovery function supported by a 299 Publication service. 301 If Key Backup is used, the key management client encrypts the private 302 key under a strong symmetric key and sends the encrypted data to the 303 publication service. The information necessary to recover the private 304 key is presented to the user in a compact form that MAY be written 305 down and stored without risk of hardware failure rendering the key 306 inaccessible. 308 2.2.1. Encrypted Private Key 310 Private Keys are encrypted using the PKCS#8 format as specified in 311 [RFC5208]. 313 This specification is prefered to the PKCS#12 [I-D.moriarty-pkcs12v1- 314 1] format as the latter is essentially a wrapper for multiple PKCS#8 315 keys and associated certificates that can be generated by a 316 publication service if necessary. 318 Key management tools MUST support the use of AES-256 to encrypt 319 private keys. AES is prefered over AES-128 for the greater number of 320 encryption cycles rather than the increased brute force work factor. 321 Applications MAY use encryption keys with lengths less than 256 bits 322 provided that the keys have a length of at least 128 bits. 324 If the key size used is shorter than the key size required by the 325 encryption algorithm, the HKDF-Expand function described in [RFC5869] 326 is used to expand the truncated key to provide the necessary number 327 of bits. 329 Keys are presented in BASE32 encoding [RFC4648] with optional 330 separators '-' to improve readability. Applications MUST ignore 331 separators when decoding the keys. 333 2.2.2. Key Splitting 335 Key Management tools MAY support the use of a key splitting scheme to 336 allow greater control over key recovery. For example, the user might 337 split their key into three parts with a requirement that two parts 338 are necessary to reconstruct the key. 340 At this point the author has a paper by Rober Blakely Snr on an out- 341 of-patent key splitting scheme but insufficient time to read the 342 paper let alone write and implement the specification. If anyone is 343 looking for something to do, that would be useful. 345 2.3. Private Key Example 347 Alice uses a key generation tool to generate a public keypair. The 348 public parameters in hexadecimal are: 350 Modulus : 351 cc 4e de a4 1d d4 66 fd 04 93 14 63 79 91 96 62 352 35 77 81 47 85 45 85 ca 11 fd 00 f1 12 c6 6a 87 353 0f 5c 31 84 7b d5 26 43 67 fe 21 df 1b c1 5a bb 354 71 bb 3b fd 9e 11 e6 54 08 74 44 16 94 d9 b3 eb 355 d8 92 8e 74 0a 54 4a 49 28 fc 08 ca a0 53 16 93 356 08 56 7a 3d 1e cb 9c 1a 59 74 e7 00 5b e6 35 c9 357 27 98 cc d0 45 29 30 48 c7 18 dd fe 7b 7f 71 68 358 81 26 ff 97 dc 5c ae 54 41 a2 b4 14 77 04 fd 7f 359 Exponent : 360 01 00 01 362 2.3.1. Key Identifier 364 KeyIdentifier: ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA 366 alice@example.com 367 Send email to Alice using encryption if and only if an 368 encryption key for Alice can be found and Alice has published 369 the email encryption policy 'encryption preferred' or stronger. 371 ?alice@example.com 372 Send email to Alice using encryption if and only if an 373 encryption key for Alice can be found, otherwise report an 374 error. 376 ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ- 377 DAA?alice@example.com 378 Send email to Alice using encryption if and only if an 379 encryption key for Alice can be found that is directly endorsed 380 under the specified key, otherwise report an error. 382 ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ- 383 DAA??alice@example.com 384 Send email to Alice using encryption if and only if an 385 encryption key for Alice can be found that is (directly or 386 indierectly) endorsed under the specified key, otherwise report 387 an error. 389 2.3.2. Private Key Backup 391 The private key component of Alice's key is as follows: 393 P : 394 f1 a7 6b 9e 81 00 1b 72 ad c3 b9 e1 1e ec c0 8e 395 50 35 80 f2 bb e4 36 88 a3 e1 d1 9e 3f 1f 38 25 396 60 5b 45 dd 45 a2 58 23 6c 8c d0 f7 0f 77 37 55 397 89 a1 05 80 9e 75 d5 8e ad 79 19 e7 91 f7 90 67 398 Q : 399 d8 6f e0 d8 58 ce ed c7 84 e9 9d b0 b9 0f 31 b7 400 b0 05 70 81 b2 e5 fa 0d da f6 b2 33 1c 1c b0 08 401 39 0d e1 a4 47 d0 9a 17 80 d2 cf 9e 15 2d ce 37 402 12 08 64 7e 3d 76 b1 a0 f9 09 66 76 8e 3c 1b 29 403 DP : 404 0a cd c3 5f f8 c0 7a 79 ac 0f 1e 16 54 7d 9d 36 405 3f 9b c4 c2 15 68 64 8f c3 53 eb 3d 39 f1 39 5f 406 62 69 72 3c 2c 4a cf c9 f5 a6 6e 09 3d a5 c4 d1 407 8c 2f a8 c1 51 54 4f 51 eb ab 88 5e f4 05 af 6d 408 DQ : 409 40 d3 39 87 f3 09 7f 64 6b e5 c0 ca 46 93 4b 73 410 d5 ef bb 23 cd 9e 5e 07 ba 56 7b 47 1d 9b 66 0a 411 00 74 ac e9 94 6c e1 4a 3a d6 69 42 d2 db 16 51 412 9e 40 0f 41 54 4d 71 a4 62 12 b3 b2 bc a5 3a 09 413 InverseQ : 414 ea 27 5d ec 2e 35 d7 77 84 4d 0e e7 4b cb 35 59 415 70 64 ac 59 61 38 e9 d9 ee 3a 07 d0 91 b2 6d 9b 416 88 50 0d 08 b5 71 d8 f0 8e 90 08 9c a8 1c f7 09 417 18 bc 0b 61 94 b1 cc cf 2e 88 3d 96 b0 6a c9 81 419 The private key is encrypted under a randomly assigned symmetric key 420 using PKCS8 encoding. 422 30 82 02 78 30 02 05 00 04 82 02 70 9d d7 00 85 423 3d e1 fb a5 6e b1 53 92 c4 cb ac e6 a3 89 25 43 424 fc 7b 07 3c 7c 33 13 56 e3 42 84 4a d5 27 f7 fc 425 47 f2 df 12 10 4a f0 83 0f 28 21 ee 77 84 4c 30 426 61 27 f6 db f9 1a a5 ca bc 49 57 42 51 53 fb ee 427 f4 77 6e d4 49 c3 a5 6f 6f 02 8b 3e 4c 01 e6 7e 428 54 1a 24 18 e9 db 0c f4 3f be 21 46 86 9a bf 33 429 1e df 5e 93 ec 64 63 82 d8 a0 b1 30 bf 4c 6b 5a 430 aa 80 3c 77 e2 98 eb 00 07 6b e5 27 52 d8 ac b4 431 c7 9a 18 00 52 40 da 13 8f 3a d6 4d f5 c8 04 90 432 2f 0d 76 3a 4b 3f 9b 0e cb fb 33 55 b5 52 78 18 433 e1 f6 a2 fb ee 99 29 26 f9 aa 00 e3 33 f2 d8 d2 434 5d 06 b0 db d9 75 eb 40 9c bc b6 3e 4d 7b 30 00 435 88 85 9d 8f ac 35 fd eb a2 98 10 b9 d5 ea 25 f3 436 44 75 78 d6 3c ff 79 16 6b 37 6c 26 cd 63 04 77 437 d9 5e 74 68 9b de f1 fe 79 be 57 8d a1 50 3a 1b 438 5d 48 33 c3 07 64 17 b7 83 31 d0 cb 49 dc ad f3 439 33 44 5f 4d 97 96 b2 c3 c2 ba 0b a9 85 d1 26 38 440 3f f0 f1 53 cf 12 ad 33 c1 9d e1 75 b0 04 56 46 441 02 0e 35 94 43 eb ec fa 4e e2 4b 0f 61 f7 3e a8 442 5e 70 a2 97 a5 5d 8d 94 79 eb 47 dd ee d0 d2 c7 443 5b 8f de 01 a9 ab c6 9f 53 71 f1 c6 0d d9 2d 71 444 b6 1b 6b 93 f7 42 7c 1f 69 1f d7 52 08 3f ca 87 445 db 23 c7 62 32 68 16 d7 ba 45 9e 38 32 3b 80 b5 446 e0 75 65 af ea 5d 4f 31 d6 17 43 0e 7c ad 66 3f 447 9b 43 c4 b7 88 75 da 08 27 93 28 eb 0d dc 10 aa 448 91 4c 22 ae 12 ae fd 58 a7 48 c4 51 16 32 e2 a7 449 3b ee 5d 62 da 56 d0 b8 c5 e2 fb 53 22 6f eb 76 450 fe 47 0d ec 86 39 c3 7a 83 2a 37 18 b0 7c 19 ad 451 b0 50 2c 25 3b eb 7c 49 9e 4b 7e a6 ea 94 86 45 452 ac 5e e6 80 36 04 11 e1 09 a1 d0 16 ff 82 b3 9d 453 2e 04 01 df 57 e2 eb 90 fa c3 23 76 9f da 97 fe 454 68 f0 8e 39 8d 71 67 18 7d 8a 8c c9 8c 92 2b 48 455 18 9a f7 60 f3 7b 94 07 ff f3 b5 e4 c7 0f 24 b5 456 89 f3 44 60 a6 54 87 d8 fc 25 3f 00 01 6c 8b 11 457 e7 05 8c 84 fe 77 fd 53 b1 e9 ea 4a a2 7a d8 12 458 a8 5b 38 10 38 81 57 18 0c 26 1b 8b 7e cc 33 53 459 dc 2d 95 6e 94 56 d0 d8 25 fb 67 dc d2 63 af 2c 460 70 50 ce a6 af bf 8f 1b ce a2 aa e6 00 00 00 00 461 00 00 00 00 00 00 00 00 00 00 00 00 463 The cipher (specified in the PKCS8 object) is AES-256. The password 464 value in Base-32 encoding is: 466 Passcode: 25ANVA-EAKZAD-HACPVJA-FXADTYC; 468 1/3: OOAPUA-AXBBAJ-2AEQ6KA-FQAFBTB 469 2/3: 7NAIPA-GRRCAG-RAHW6HA-FSAB5SD 470 3/3: VJAENA-BYO6AH-UAAGD6A-LIABUOD 472 3. Public Key Infrastructure 474 The precise means by which a public key is validated by a relying 475 party is outside the scope of this specification. Keys MAY be 476 validated by a traditional Certificate Authority or through peer to 477 peer endorsement or any combination of the two. 479 In order to maximize the flexibility for the trust infrastructre 480 designers, two syntaxes for presenting public keys for use are 481 supported. Key Management tools SHOULD support both: 483 A Certificate Signing Request 484 May be presented to a CA or other signer. 486 A self signed certificate 487 Presents the public key in a form that many Internet 488 applications accept directly. 490 3.1. Certificate Signing Request. 492 Certificate Signing Requests SHOULD conform to the following profile: 494 * The Key Identifier MUST be specified and MUST be a strong key 495 identifier 497 * [[Prohibit various PKIX lunacies] 499 3.2. Self-Signed Certificate. 501 Self Signed Certificates SHOULD conform to the following profile: 503 * The Key Identifier MUST be specified and MUST be a strong key 504 identifier 506 * [[Prohibit various PKIX lunacies] 508 3.3. Peer Endorsement 510 Traditionally PKIX only permits use of Certification Authority 511 provided trust assertions while OpenPGP only permits use of peer 512 endorsement through key signing. PPE supports the use of a 513 combination of both approaches for reasons described in [I- 514 D.hallambaker-prismproof-trust] 516 To perform peer endorsement, the following data structure is used: 518 Class Endorsement 519 TBSEndorsement TBSEndorsement 520 SignatureAlgorithm AlgorithmIdentifier 521 Signature Bits 523 Class TBSEndorsement 524 Version Integer 525 Issued Time 526 IssuerKeyIdentifier Octets 527 SubjectKeyIdentifier Octets 528 Subject List Name 529 SubjectAltName List SubjectAltName 530 Extensions List Extension 532 Class AlgorithmIdentifier 533 Algorithm OIDRef 534 Parameters Any 536 Class Name 537 Member Set AttributeTypeValue 539 Class AttributeTypeValue 540 Type OIDRef 541 Value AnyString 543 Object SubjectAltName id_ce_subjectAltName 544 Names List GeneralName 546 Class GeneralName 547 Value Choice 548 RFC822Name IA5String 549 Code 1 550 Implicit 551 DNSName IA5String 552 Code 2 553 Implicit 555 Class Extension 556 ObjectIdentifier OIDRef 557 Critical Boolean 558 Default "false" 559 Optional 560 Data Octets 562 [[Note that although my tool generates ASN.1 encoding this is for 563 purely pragmatic reasons of providing consistency. It is not meant to 564 in any shape or fashion stand for an endorsement of this crackpot 565 technology.] 567 A new structure is introduced to support Key Endorsement rather than 568 attempting to re-use the X.509v3 Certificate format in recognition of 569 key endorsement having distinctly different semantics from issue of 570 PKIX certificates. PKIX certificates are either end entity 571 certificates or certificate signing certificates. A PKIX certificate 572 is expressly prohibited from being used for both purposes. In the 573 PKIX model, finding a certificate chain to a trusted anchor is 574 necessary and sufficient to establish the trustworthiness of an end 575 entity certificate. In the Key Endorsement model the reliance on a 576 single key endorsement MAY be qualified by the age of the 577 endorsement, the circumstances of issue, the number of independent 578 trust paths from the relying party to the subject and the lengths of 579 each path. 581 Most of the fields in the TBSEndorsement structure have the same 582 semantics as in PKIX with the exception of the Validity interval 583 which is replaced by the time of issue. 585 The precise mechanism by which endorsement is used requires further 586 development. At minimum, the endorsement mechanism should allow the 587 following forms of endorsement to be differentiated: 589 Direct Endorsement 590 A endorsement of a user's key identifier by another key held by 591 the same user. This form of endorsement allows a user to 592 establish a personal master key that is only used for the 593 purpose of endorsing keys for specific uses (email encryption, 594 email signature, endorsement, etc.) 596 Peer Endorsement 597 A user endorses the key identifier of another user (the 598 subject) and possibly other aspects of the subject's identity 599 such as their name, likeness etc. Such an endorsement SHOULD 600 specify the basis for the endorsement (in person, remote, 601 recent acquaintance, verification of government documents, 602 childhood friend, etc.) 604 Group Endorsement 605 One of the use practices that has emerged from attempts to 606 employ PGP is the 'key party' in which groups of users perform 607 mutual keysigning. 609 Withdrawing an Endorsement 610 In certain circumstances, it MAY be necessary to withdraw an 611 endorsement. The reason for withdrawing the endorsement SHOULD 612 be specified in the UnEndorsement notice and MAY include, 613 notification of the loss of the private key, the subject is 614 deceased, etc.) 616 4. Publication Service 618 The Publication Service is a JSON/REST Web Service layered over HTTP 619 transport. Although the publication service performs an important 620 service, it is not a service trusted by the user since the 621 publication service has no access to the user's private key (except 622 in encrypted form) and does not sign any data that is read by the 623 user. 625 The Publication Service is one of the two interfaces between the part 626 of the email message security problem that is well understood and the 627 part that is widely regarded to be 'research'. 629 Selection of the publication service MAY be left to individual user 630 choice or a domain name holder MAY specify that publication requests 631 be directed to a specific publication service. Users of a public 632 email service are likely to want to insist on their own choice of 633 publication service while a bank or government enterprise that has 634 deployed its own security infrastructure is likely to want to insist 635 that only credentials they approve are accepted for their site. 637 To allow researchers the widest possible lattitude in developing new 638 trust infrastructures, publication of three trust assertion formats 639 are supported together with support for key backup and recovery. 640 These assertion formats are: 642 Self Signed Certificate 643 A PKIX self signed certificate which MAY be used in conjunction 644 with an existing application that accepts public key 645 information in self signed certificate form. 647 Certificate Signing Request 648 A PKCS#10 Certificate Signing Request conforming to [!RFC2986]. 649 A publication interface MAY forward the Certificate Signing 650 request to a Certificate Authority for issue of a PKIX end 651 entity certificate. 653 Key Endorsement 654 A Key Endorsement in the format described in this document. 656 4.1. Initial Key Publication 658 The first time that the Publication Service is used is after the user 659 generates a new keypair. 661 For example, Alice registers the keypair generated in the previous 662 example with her chosen Publication Service. Her key management tool 663 makes an Assert request to the service with the following 664 information: 666 * The Strong Key Identifier 668 * The Encrypted Private Key 670 * A Self-Signed Certificate 672 * A Signed Certificate Signing Request 674 * Service information describing the email service parameters to 675 be used when sending messages using the corresponding email 676 account. [[Which really should be encrypted, shouldn't they?] 678 5. Registration Example 680 Request 682 { 683 "AssertRequest": { 684 "KeyIdentifier": " 685 AERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keU", 686 "EncryptedKey": { 687 "EncryptedPrivateKey": " 688 MIICeDACBQAEggJwndcAhT3h-6VusVOSxMus5qOJJUP8ewc8fDMTVuNChErVJ_f8 689 R_LfEhBK8IMPKCHud4RMMGEn9tv5GqXKvElXQlFT--70d27UScOlb28Ciz5MAeZ- 690 VBokGOnbDPQ_viFGhpq_Mx7fXpPsZGOC2KCxML9Ma1qqgDx34pjrAAdr5SdS2Ky0 691 x5oYAFJA2hOPOtZN9cgEkC8NdjpLP5sOy_szVbVSeBjh9qL77pkpJvmqAOMz8tjS 692 XQaw29l160CcvLY-TXswAIiFnY-sNf3ropgQudXqJfNEdXjWPP95Fms3bCbNYwR3 693 2V50aJve8f55vleNoVA6G11IM8MHZBe3gzHQy0ncrfMzRF9Nl5ayw8K6C6mF0SY4 694 P_DxU88SrTPBneF1sARWRgIONZRD6-z6TuJLD2H3PqhecKKXpV2NlHnrR93u0NLH 695 W4_eAamrxp9TcfHGDdktcbYba5P3QnwfaR_XUgg_yofbI8diMmgW17pFnjgyO4C1 696 4HVlr-pdTzHWF0MOfK1mP5tDxLeIddoIJ5Mo6w3cEKqRTCKuEq79WKdIxFEWMuKn 697 O-5dYtpW0LjF4vtTIm_rdv5HDeyGOcN6gyo3GLB8Ga2wUCwlO-t8SZ5LfqbqlIZF 698 rF7mgDYEEeEJodAW_4KznS4EAd9X4uuQ-sMjdp_al_5o8I45jXFnGH2KjMmMkitI 699 GJr3YPN7lAf_87Xkxw8ktYnzRGCmVIfY_CU_AAFsixHnBYyE_nf9U7Hp6kqietgS 700 qFs4EDiBVxgMJhuLfswzU9wtlW6UVtDYJftn3NJjryxwUM6mr7-PG86iquYAAAAA 701 AAAAAAAAAAAAAAAA"}, 702 "Certificate": [" 703 MIICMDCCAaQAAQICEC9SGLG5FJwVSb5qRQGMdGAwAgUAMAQwAjEAMB4XDTEzMTEw 704 MTEyMDAwMVoXDTMzMTExNjA1MDA0NFowBDACMQAwgZQwAgUAA4GNADCBiQKBgQDM 705 Tt6kHdRm_QSTFGN5kZZiNXeBR4VFhcoR_QDxEsZqhw9cMYR71SZDZ_4h3xvBWrtx 706 uzv9nhHmVAh0RBaU2bPr2JKOdApUSkko_AjKoFMWkwhWej0ey5waWXTnAFvmNckn 707 mMzQRSkwSMcY3f57f3FogSb_l9xcrlRBorQUdwT9fwIDAQABAQACACOBwTApBgMO 708 HVUCAQAEHwQdAERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keUwMAYDIx1VAgEA 709 BCYwJAAdAERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keUBAAIBADAlBgMRHVUC 710 AQAEGzAZMBcwFQUAFhFhbGljZUBleGFtcGxlLmNvbTAQBgMPHVUCAf8EBgMEAAcA 711 gDAYBgMlHVUCAQAEDjAMMAoGCAQDBwUFAQYrMA8GAxMdVQIBAAQFMAMCAQAwAgUA 712 A4GBAApColS86hwM0t2ehZyH1-sXS6kL95WBRquKpdjspok_Bts4Y1sXjgiiu6AY 713 S9o_Y5vu4-mftgEwiTfhqrh_AJ_FcdD7Mohglo2O8b1lvfLXqoiRjLsAEF79M9A5 714 UWHf6t-WyaYvu6QBfEvESbvDpzndn3pFGmgjETrAPwZwY4AG"], 715 "CertificateRequest": [" 716 MIIBLTCBogIBADAEMAIxADCBlDACBQADgY0AMIGJAoGBAMxO3qQd1Gb9BJMUY3mR 717 lmI1d4FHhUWFyhH9APESxmqHD1wxhHvVJkNn_iHfG8Fau3G7O_2eEeZUCHREFpTZ 718 s-vYko50ClRKSSj8CMqgUxaTCFZ6PR7LnBpZdOcAW-Y1ySeYzNBFKTBIxxjd_nt_ 719 cWiBJv-X3FyuVEGitBR3BP1_AgMBAAEAADACBQADgYEApg6BVGJsxnjRAiYTGMp9 720 QZX00qSOszIy19u0lWbrVaXl7I4Pz7vfDr3i3ZZNYiWOy70iuY6l-FjLlnkEN_ou 721 ZIjDicxP5lVqJPfmNckDqIm8KcJ9QPCYNZiSSWYQFPk_4PrEn9wYCTMVn2E2kmZV 722 YfOBXlmrR6shpwmgf32sJyU"], 723 "Service": [{ 724 "Email": "alice@example.com", 725 "Name": "smtp.example.com", 726 "Protocol": "_smtp._tls", 727 "Port": 587, 728 "TLS": true}, 729 { 730 "Email": "alice@example.com", 731 "Name": "imap.example.com", 732 "Protocol": "_smtp._tls", 733 "Port": 993, 734 "TLS": true}]}} 736 Response 738 { 739 "AssertResponse": {}} 741 5.1. Enabling a new Device 743 Alice uses several different devices to read her email and she would 744 like to be able to read encrypted emails on all of them. This 745 requires that the private key be installed on each of the devices 746 that she might want to use. 748 Alice provides either the Key Recovery Passcode or a sufficient 749 number of Key Shares to reconstruct the passcode to the key 750 management tool running on each device. The device then requests 751 recovery of the private key and associated service information: 753 6. Recovery Example 755 Request 757 { 758 "RecoverRequest": { 759 "KeyIdentifier": " 760 AERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keU"}} 762 Response 764 { 765 "RecoverResponse": {}} 767 Providing the service information with the private key allows the key 768 recovery tool to automate configuration of the user's email account 769 on the device if this has not been done already. 771 Using the key recovery mechanism to support key transport between 772 devices simplifies the initial coding task at the cost of a sub- 773 optimal user experience for the user with a large number of devices 774 in use and/or frequent key updates. 776 Future versions of the specification may adopt a different approach 777 to key recovery in which each device in which keys are to be 778 installed establishes a device specific keypair which is in turn used 779 to automate the key transport. A key concern in the design of such a 780 scheme being to prevent a weak random number generator on one device 781 causing the private key to be compromised. 783 6.1. Revocation 785 Should the private key be lost, the subject be deceased or some other 786 event occur that renders the key no longer servicable, a revocation 787 statement is generated and issued. Such revocation statements use the 788 Revoke request and the key endorsement message format: 790 7. Revocation Example 792 Request 794 { 795 "RevokeRequest": {}} 797 Response 799 { 800 "RevokeResponse": {}} 802 7.1. Key Endorsement 804 From time to time, Alice meets other PPE users and they endorse each 805 other's keys. The AssertRequest is used to submit one or more signed 806 key endorsements: 808 8. Endorsement Example 810 Request 812 { 813 "AssertRequest": { 814 "Endorsement": [" 815 MIH5MG8CAQAXDTEzMTEwMTA1MDA0NFoEHQBEcgko4DafOU68FQ-U7xq7ce2Sblcq 816 xuazOpHlBB0A6_lnsF7kAUEy_oGLvM-BbXuYjLjVJQ5YPMWHHQUAMBkwFzAVMBMF 817 ABYPYm9iQGV4YW1wbGUuY29tBQAwAgUAA4GBAIrZK5W4Vi9dAk0LPlEMkP5JQxBC 818 XHUJ5I9gEMithdJvyE0uZTwedhUlG30YEvRJXkizkJUriAIhNdTQU2YpANyICZHF 819 27CO-I09d2TGOkmbuuadi-QmH9dgdEmRpBWIOmVcF6mXnRRyG8M4cVbetK9TRqwX 820 NnlHucuKDA_VIAx9"]}} 821 Response 823 { 824 "AssertResponse": {}} 826 A key endorsement MAY be submitted to the Publication Interface by 827 any party including the signer or the subject. 829 9. OmniAssertBroker 831 9.1. OmniAssertBroker Transactions 833 9.1.1. Assert 835 * Request: AssertRequest 837 * Response: AssertResponse 839 Register an assertion set. 841 The Assert transaction is used when a keypair is first created to 842 register the new Key Identifier, Self Signed Certificate and 843 Certificate Signing Request and to request revision of embedded 844 attributes such as the email security policy. 846 The Assert transaction is also used to request registration of Key 847 Endorsements. 849 9.1.2. Recover 851 * Request: RecoverRequest 853 * Response: RecoverResponse 855 Recover a previously registered encrypted private key file from the 856 service 858 If the Key Identifier cannot be found or there is no release code 859 associated with the encrypted private key, the transaction is 860 complete after the first response. Otherwise the service returns the 861 status code 'ChallengeResponse' in response to the initial request 862 and the client MUST make a second request in which it establishes 863 proof of knowledge of the release code to complete the transaction. 865 9.1.3. Revoke 867 * Request: RevokeRequest 869 * Response: RevokeResponse 871 Publish a revocation meta-assertion 873 9.2. OmniAssertBroker Messages 875 9.2.1. Message: AssertRequest 877 Register an assertion set 879 At present only a single Key Identifier may be registered per request 880 and no provision is made to link related requests. This is likely to 881 become necessary when different keys are being used for key 882 endorsement, signature, encryption and master purposes. 884 KeyIdentifier : 885 Binary [1..1] Strong Key Identifier formed using a message 886 digest function over the DER encoded Public Key Info block. 888 EncryptedKey : 889 EncryptedKey [0..1] Encrypted Private Key and associated 890 attributes. 892 Certificate : 893 Binary [0..Many] PKIX Certificates to be registered, comply 894 with [!RFC5280] and additional profile constraints specified 895 here. 897 CertificateRequest : 898 Binary [0..Many] Certificate Request in [!RFC2986] format. 900 Endorsement : 901 Binary [0..Many] Key Endorsements as specified in this 902 document. 904 Service : 905 Service [0..Many] Service connection information for associated 906 services. For example, email IMAP [!RFC3501], POP3 [!RFC5034] 907 and SUBMIT [!RFC4409] accounts. 909 9.2.2. Message: AssertResponse 911 Response to an assertion registration request. 913 It may be useful to expand the response to allow the gateway to 914 provide information such as certificates issued in response to the 915 certification request but these will typically require some form of 916 validation and thus be returned asynchronously. 918 9.2.3. Message: RecoverRequest 920 Request recovery of a previously registered encrypted private key. 922 KeyIdentifier : 923 Binary [1..1] Key Identifier of key pair for which recovery of 924 the private key is being requested. 926 Challenge : 927 Binary [0..1] Client challenge value for proof of knowledge of 928 the release code. 930 Answer : 931 Binary [0..1] Answer value for proof of knowledge of the 932 release code. 934 9.2.4. Message: RecoverResponse 936 Respond to a recovery request. 938 If the encrypted private key associated with the specified Key 939 Identifier has an associated 941 EncryptedPrivateKey : 942 Binary [0..1] PKCS#8 Encrypted Private Key as specified in 943 [!RFC5208]. 945 Challenge : 946 Binary [0..1] Server challenge value for proof of knowledge of 947 the release code. 949 Algorithm : 950 String [0..1] Digest algorithm for proof of knowledge of the 951 release code. 953 9.2.5. Message: RevokeRequest 955 Regquest revocation of a previously registered key and all related 956 certificates and endorsements. 958 Note that whil key revocation necessarily entails revocation of all 959 the certificates and endorsement associated with the key, the reverse 960 is not the case. A user may revoke a certificate granting use of a 961 key for encrypted email without wishing to revoke a certificate for 962 the same key granting use for signed email. 964 KeyIdentifier : 965 Binary [1..1] Key Identifier of Key to be revoked. 967 Notice : 968 Binary [0..1] Signed Key Endorsement object with the 'revoke' 969 attribute specified. 971 9.2.6. Message: RevokeResponse 973 Response to revocation request. 975 9.3. OmniAssertBroker Structures 977 9.3.1. Structure: Service 979 Email : 980 String [0..1] Principal Email address associated with the 981 account 983 OtherEmail : 984 String [0..Many] Additional Email addresses associated with the 985 account. 987 Name : 988 String [0..1] DNS Address of Service 990 Protocol : 991 String [0..1] SRV format protocol identification prefix. 993 Port : 994 Integer [0..1] IP Port number 996 TLS : 997 Boolean [0..1] If true, use of TLS is required 999 Security : 1000 String [0..1] Security policy description 1002 9.3.2. Structure: EncryptedKey 1004 EncryptedPrivateKey : 1005 Binary [1..1] PKCS#8 Encrypted Private Key as specified in 1006 [!RFC5208]. 1008 PFX : 1009 Binary [0..1] PKCS#12 Encrypted Private Key as specified in 1010 [!~I-D.moriarty-pkcs12v1-1]. 1012 ReleaseCode : 1013 Binary [0..1] Release Code value for authorizing private key 1014 recovery requests. If specified the service MUST NOT release 1015 the encrypted private key unless the requestor satisfies a 1016 challenge-response request that establishes knowledge of the 1017 Release Code. 1019 10. Security Considerations 1021 I am sure there are some. 1023 11. Acknowledgments 1025 Thanks to the many people who have encouraged me in this work and in 1026 particular the members of the IETF PERPASS list and the Cryptography 1027 mailing list. Future versions of the draft will have a more complete 1028 list. 1030 12. References 1032 12.1. Normative References 1034 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1035 4rev1", RFC 3501, March 2003. 1037 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 1038 R.,Polk, W., "Internet X.509 Public Key Infrastructure 1039 Certificate and Certificate Revocation List (CRL) 1040 Profile", RFC 5280, May 2008. 1042 [RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 1043 Syntax Specification Version 1.7", RFC 2986, November 1044 2000. 1046 [~I-D.moriarty-pkcs12v1-1] , "[Reference Not Found!]". 1048 [RFC4409] ,Gellens, R.,Klensin, J., "Message Submission for Mail", 1049 RFC 4409, April 2006. 1051 [RFC5034] Siemborski, R.,Menon-Sen, A., "The Post Office Protocol 1052 (POP3) Simple Authentication and Security Layer (SASL) 1053 Authentication Mechanism", RFC 5034, July 2007. 1055 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 1056 Private-Key Information Syntax Specification Version 1.2", 1057 RFC 5208, May 2008. 1059 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1060 2001. 1062 [RFC4880] Callas, J.,Donnerhacke, L.,Finney, H.,Shaw, D.,Thayer, R., 1063 "OpenPGP Message Format", RFC 4880, November 2007. 1065 [I-D.hallambaker-prismproof-trust] Hallam-Baker, P, "PRISM Proof 1066 Trust Model", Internet-Draft draft-hallambaker-prismproof- 1067 trust-00, 16 October 2013. 1069 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1070 Encodings", RFC 4648, October 2006. 1072 [RFC5869] Krawczyk, H.,Eronen, P., "HMAC-based Extract-and-Expand 1073 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1075 12.2. Informative References 1077 [I-D.moriarty-pkcs12v1-1] Moriarty, K,Nystrom, M,Parkinson, S,Rusch, 1078 A,Scott, M, "PKCS 12 v1: Personal Information Exchange 1079 Syntax", Internet-Draft draft-moriarty-pkcs12v1-1-01, 25 1080 March 2013. 1082 [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, 1083 L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol 1084 -- HTTP/1.1", RFC 2616, June 1999. 1086 [RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security 1087 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1089 Author's Address 1091 Phillip Hallam-Baker 1092 Comodo Group Inc. 1094 philliph@comodo.com