| Network Working Group | P. Hallam_Baker |
| Internet-Draft | Comodo Group Inc. |
| Expires: April 30, 2015 | October 27, 2014 |
PRISM_Proof Email Key Generation and Publication
draft-hallambaker-prismproof-key-01
This document describes previous efforts and their deployment legacy and the requirements for a successful email security infrastructure. A gap analysis is performed and the tasks divided into problems that are generally considered solved albeit possibly requiring improved execution and problems that may be regarded as research.
This division of the problem space into 'execution' and 'research' portions allows different groups of developers to address each independently and avoid unnecessary duplication of effort. A testbed for development and early adopter deployment that achieves this separation is described.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Generating a public keypair and registering it for use should be the only occasion on which a user is required to think about their cryptographic security. Nor should the user be required to think too much in this circumstance either.
To enable others to send encrypted email to them, a user must at minimum generate at least one public keypair and make the public key portion available to the intended communit of potential senders. The precise means by which this is achieved may be considered a hard research problem. Accordingly this specification anticipates such processing being performed 'in the cloud' (i.e. by magic) and describes a Web Service interface that may be used to
Twenty years of effort attempting to deploy secure email has left a considerable legacy of deployed code. While this deployed code base is not ideally suited to the task (or the problem would be solved already) it is generally better to support use of such deployed resources where they exist rather than attempt to build everything from scratch.
One significant design consequence that flows from this approach is to adopt ASN.1 encoding for cryptagraphic data objects, including the Key Endorsement object described in this document. While there are many better choices of data encoding and remarkably few that are worse, most cryptographic toolkits provide support for parsing X.509v3 certificates and generating Certificate Signing Requests and many provide comprehensive support for a wide range of ASN.1 encoded objects.
A Strong Key Identifier is an identifier that identifies a unique public key formed using a strong Message digest function over the public key parameter values.
This definition of Key Identifiers is considerably more restrictive than the PKIX definition which allows an issuer to use any unique string for the subjectKeyIdentifier and authorityKeyIdentifier extensions.
Compliant certificate issuers SHOULD use Strong Key Identifiers as specified in this document for PKIX Key Identifiers.
A strong Key Identifier takes one of the two following forms:
The following algorithm values are assigned in this document:
To prevent a downgrade attack in which an attacker truncates a longer Key Identifier, the input to the message digest function is prepared as follows:
Let V be the algorithm identifier value and D be the DER encoded SubjectPublicKeyInfo and + stand for simple concatenation.
Key Identifier = H (V + D)
If it is necessary to present a Key Identifier to an end user, Base32 encoding is used. Additional dash (-) characters MAY be added to improve readability and MUST be ignored by compliant applications.
To establish encrypted communications it is necessary to know a public key for the recipient and the recipient's security policy. The fact that a recipient is capable of receiving encrypted email does not mean that they are capable of receiving encrypted email on every device they use or that they are willing to accept encrypted email from every sender.
A similar problem was faced when using Transport Layer Security [RFC5246] with HTTP [RFC2616]. By default, Web requests are sent without use of security. To force use of TLS, the URI method https is used in place of http. The security policy is encoded in the URI.
Strong email addresses allow an email sender to encode the security policy in an RFC822 [RFC2822] compliant email address. RFC822 defines the 'user name' portion of an email address as follows:
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
In a Strong Email Address, the character '?' is reserved. Although this is a legitimate account name in some operating systems, use is prohibited in current editions of Windows and most UNIX based operating systems.
The address syntax is modified as follows:
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string /
obs-local-part / strong-local
atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
strong-local = indirect-key / direct-key / nokey
ktext = ALPHA / DIGIT / "-"
key-identifier = 1*ktext
indirect-key = key-identifier "??" dot-atom
direct-key = key-identifier "?" dot-atom
nokey = "?" dot-atom
Addresses of the form indirect-key, direct-key and nokey are interpreted as follows:
A frequently overlooked hazzard of using encryption is the risk of data loss should the private key be lost or otherwise become unavailable. Another practical difficulty that must be faced is the need to enable encrypted email to be read on more than one device. Once published, a strong email identifier effectively becomes a personal root of trust, the value of which may increase over time.
Each of these use cases requires some form of private key backup and recovery mechanism. While such mechanisms have traditionally been considered to be an implementation choice that is outside the scope of a protocol specification, to do so incurs a substantial risk of a large number of bad implementation choices. In particular the need to enable receipt of email on multiple devices requires a standards based approach or else applications provided by different vendors will not be able to exchange keys.
While a Key Escrow capability provides a Key Backup capability, the reverse is not true. A Key Escrow system is generally understood to support recovery of the private key without notice to the private key holder while a Key Backup system need not meet this requirement.
A publication service MAY support Key Backup and Recovery. A user MAY choose to use the Key Backup and Recovery function supported by a Publication service.
If Key Backup is used, the key management client encrypts the private key under a strong symmetric key and sends the encrypted data to the publication service. The information necessary to recover the private key is presented to the user in a compact form that MAY be written down and stored without risk of hardware failure rendering the key inaccessible.
Private Keys are encrypted using the PKCS#8 format as specified in [RFC5208].
This specification is prefered to the PKCS#12 [I-D.moriarty-pkcs12v1-1] format as the latter is essentially a wrapper for multiple PKCS#8 keys and associated certificates that can be generated by a publication service if necessary.
Key management tools MUST support the use of AES-256 to encrypt private keys. AES is prefered over AES-128 for the greater number of encryption cycles rather than the increased brute force work factor. Applications MAY use encryption keys with lengths less than 256 bits provided that the keys have a length of at least 128 bits.
If the key size used is shorter than the key size required by the encryption algorithm, the HKDF-Expand function described in [RFC5869] is used to expand the truncated key to provide the necessary number of bits.
Keys are presented in BASE32 encoding [RFC4648] with optional separators '-' to improve readability. Applications MUST ignore separators when decoding the keys.
Key Management tools MAY support the use of a key splitting scheme to allow greater control over key recovery. For example, the user might split their key into three parts with a requirement that two parts are necessary to reconstruct the key.
At this point the author has a paper by Rober Blakely Snr on an out-of-patent key splitting scheme but insufficient time to read the paper let alone write and implement the specification. If anyone is looking for something to do, that would be useful.
Alice uses a key generation tool to generate a public keypair. The public parameters in hexadecimal are:
Modulus : cc 4e de a4 1d d4 66 fd 04 93 14 63 79 91 96 62 35 77 81 47 85 45 85 ca 11 fd 00 f1 12 c6 6a 87 0f 5c 31 84 7b d5 26 43 67 fe 21 df 1b c1 5a bb 71 bb 3b fd 9e 11 e6 54 08 74 44 16 94 d9 b3 eb d8 92 8e 74 0a 54 4a 49 28 fc 08 ca a0 53 16 93 08 56 7a 3d 1e cb 9c 1a 59 74 e7 00 5b e6 35 c9 27 98 cc d0 45 29 30 48 c7 18 dd fe 7b 7f 71 68 81 26 ff 97 dc 5c ae 54 41 a2 b4 14 77 04 fd 7f Exponent : 01 00 01
KeyIdentifier: ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA
The private key component of Alice's key is as follows:
P : f1 a7 6b 9e 81 00 1b 72 ad c3 b9 e1 1e ec c0 8e 50 35 80 f2 bb e4 36 88 a3 e1 d1 9e 3f 1f 38 25 60 5b 45 dd 45 a2 58 23 6c 8c d0 f7 0f 77 37 55 89 a1 05 80 9e 75 d5 8e ad 79 19 e7 91 f7 90 67 Q : d8 6f e0 d8 58 ce ed c7 84 e9 9d b0 b9 0f 31 b7 b0 05 70 81 b2 e5 fa 0d da f6 b2 33 1c 1c b0 08 39 0d e1 a4 47 d0 9a 17 80 d2 cf 9e 15 2d ce 37 12 08 64 7e 3d 76 b1 a0 f9 09 66 76 8e 3c 1b 29 DP : 0a cd c3 5f f8 c0 7a 79 ac 0f 1e 16 54 7d 9d 36 3f 9b c4 c2 15 68 64 8f c3 53 eb 3d 39 f1 39 5f 62 69 72 3c 2c 4a cf c9 f5 a6 6e 09 3d a5 c4 d1 8c 2f a8 c1 51 54 4f 51 eb ab 88 5e f4 05 af 6d DQ : 40 d3 39 87 f3 09 7f 64 6b e5 c0 ca 46 93 4b 73 d5 ef bb 23 cd 9e 5e 07 ba 56 7b 47 1d 9b 66 0a 00 74 ac e9 94 6c e1 4a 3a d6 69 42 d2 db 16 51 9e 40 0f 41 54 4d 71 a4 62 12 b3 b2 bc a5 3a 09 InverseQ : ea 27 5d ec 2e 35 d7 77 84 4d 0e e7 4b cb 35 59 70 64 ac 59 61 38 e9 d9 ee 3a 07 d0 91 b2 6d 9b 88 50 0d 08 b5 71 d8 f0 8e 90 08 9c a8 1c f7 09 18 bc 0b 61 94 b1 cc cf 2e 88 3d 96 b0 6a c9 81
The private key is encrypted under a randomly assigned symmetric key using PKCS8 encoding.
30 82 02 78 30 02 05 00 04 82 02 70 9d d7 00 85 3d e1 fb a5 6e b1 53 92 c4 cb ac e6 a3 89 25 43 fc 7b 07 3c 7c 33 13 56 e3 42 84 4a d5 27 f7 fc 47 f2 df 12 10 4a f0 83 0f 28 21 ee 77 84 4c 30 61 27 f6 db f9 1a a5 ca bc 49 57 42 51 53 fb ee f4 77 6e d4 49 c3 a5 6f 6f 02 8b 3e 4c 01 e6 7e 54 1a 24 18 e9 db 0c f4 3f be 21 46 86 9a bf 33 1e df 5e 93 ec 64 63 82 d8 a0 b1 30 bf 4c 6b 5a aa 80 3c 77 e2 98 eb 00 07 6b e5 27 52 d8 ac b4 c7 9a 18 00 52 40 da 13 8f 3a d6 4d f5 c8 04 90 2f 0d 76 3a 4b 3f 9b 0e cb fb 33 55 b5 52 78 18 e1 f6 a2 fb ee 99 29 26 f9 aa 00 e3 33 f2 d8 d2 5d 06 b0 db d9 75 eb 40 9c bc b6 3e 4d 7b 30 00 88 85 9d 8f ac 35 fd eb a2 98 10 b9 d5 ea 25 f3 44 75 78 d6 3c ff 79 16 6b 37 6c 26 cd 63 04 77 d9 5e 74 68 9b de f1 fe 79 be 57 8d a1 50 3a 1b 5d 48 33 c3 07 64 17 b7 83 31 d0 cb 49 dc ad f3 33 44 5f 4d 97 96 b2 c3 c2 ba 0b a9 85 d1 26 38 3f f0 f1 53 cf 12 ad 33 c1 9d e1 75 b0 04 56 46 02 0e 35 94 43 eb ec fa 4e e2 4b 0f 61 f7 3e a8 5e 70 a2 97 a5 5d 8d 94 79 eb 47 dd ee d0 d2 c7 5b 8f de 01 a9 ab c6 9f 53 71 f1 c6 0d d9 2d 71 b6 1b 6b 93 f7 42 7c 1f 69 1f d7 52 08 3f ca 87 db 23 c7 62 32 68 16 d7 ba 45 9e 38 32 3b 80 b5 e0 75 65 af ea 5d 4f 31 d6 17 43 0e 7c ad 66 3f 9b 43 c4 b7 88 75 da 08 27 93 28 eb 0d dc 10 aa 91 4c 22 ae 12 ae fd 58 a7 48 c4 51 16 32 e2 a7 3b ee 5d 62 da 56 d0 b8 c5 e2 fb 53 22 6f eb 76 fe 47 0d ec 86 39 c3 7a 83 2a 37 18 b0 7c 19 ad b0 50 2c 25 3b eb 7c 49 9e 4b 7e a6 ea 94 86 45 ac 5e e6 80 36 04 11 e1 09 a1 d0 16 ff 82 b3 9d 2e 04 01 df 57 e2 eb 90 fa c3 23 76 9f da 97 fe 68 f0 8e 39 8d 71 67 18 7d 8a 8c c9 8c 92 2b 48 18 9a f7 60 f3 7b 94 07 ff f3 b5 e4 c7 0f 24 b5 89 f3 44 60 a6 54 87 d8 fc 25 3f 00 01 6c 8b 11 e7 05 8c 84 fe 77 fd 53 b1 e9 ea 4a a2 7a d8 12 a8 5b 38 10 38 81 57 18 0c 26 1b 8b 7e cc 33 53 dc 2d 95 6e 94 56 d0 d8 25 fb 67 dc d2 63 af 2c 70 50 ce a6 af bf 8f 1b ce a2 aa e6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The cipher (specified in the PKCS8 object) is AES-256. The password value in Base-32 encoding is:
Passcode: 25ANVA-EAKZAD-HACPVJA-FXADTYC;
1/3: OOAPUA-AXBBAJ-2AEQ6KA-FQAFBTB 2/3: 7NAIPA-GRRCAG-RAHW6HA-FSAB5SD 3/3: VJAENA-BYO6AH-UAAGD6A-LIABUOD
The precise means by which a public key is validated by a relying party is outside the scope of this specification. Keys MAY be validated by a traditional Certificate Authority or through peer to peer endorsement or any combination of the two.
In order to maximize the flexibility for the trust infrastructre designers, two syntaxes for presenting public keys for use are supported. Key Management tools SHOULD support both:
Certificate Signing Requests SHOULD conform to the following profile:
Self Signed Certificates SHOULD conform to the following profile:
Traditionally PKIX only permits use of Certification Authority provided trust assertions while OpenPGP only permits use of peer endorsement through key signing. PPE supports the use of a combination of both approaches for reasons described in [I-D.hallambaker-prismproof-trust]
To perform peer endorsement, the following data structure is used:
Class Endorsement TBSEndorsement TBSEndorsement SignatureAlgorithm AlgorithmIdentifier Signature Bits Class TBSEndorsement Version Integer Issued Time IssuerKeyIdentifier Octets SubjectKeyIdentifier Octets Subject List Name SubjectAltName List SubjectAltName Extensions List Extension Class AlgorithmIdentifier Algorithm OIDRef Parameters Any Class Name Member Set AttributeTypeValue Class AttributeTypeValue Type OIDRef Value AnyString Object SubjectAltName id_ce_subjectAltName Names List GeneralName Class GeneralName Value Choice RFC822Name IA5String Code 1 Implicit DNSName IA5String Code 2 Implicit Class Extension ObjectIdentifier OIDRef Critical Boolean Default "false" Optional Data Octets
[[Note that although my tool generates ASN.1 encoding this is for purely pragmatic reasons of providing consistency. It is not meant to in any shape or fashion stand for an endorsement of this crackpot technology.]
A new structure is introduced to support Key Endorsement rather than attempting to re-use the X.509v3 Certificate format in recognition of key endorsement having distinctly different semantics from issue of PKIX certificates. PKIX certificates are either end entity certificates or certificate signing certificates. A PKIX certificate is expressly prohibited from being used for both purposes. In the PKIX model, finding a certificate chain to a trusted anchor is necessary and sufficient to establish the trustworthiness of an end entity certificate. In the Key Endorsement model the reliance on a single key endorsement MAY be qualified by the age of the endorsement, the circumstances of issue, the number of independent trust paths from the relying party to the subject and the lengths of each path.
Most of the fields in the TBSEndorsement structure have the same semantics as in PKIX with the exception of the Validity interval which is replaced by the time of issue.
The precise mechanism by which endorsement is used requires further development. At minimum, the endorsement mechanism should allow the following forms of endorsement to be differentiated:
The Publication Service is a JSON/REST Web Service layered over HTTP transport. Although the publication service performs an important service, it is not a service trusted by the user since the publication service has no access to the user's private key (except in encrypted form) and does not sign any data that is read by the user.
The Publication Service is one of the two interfaces between the part of the email message security problem that is well understood and the part that is widely regarded to be 'research'.
Selection of the publication service MAY be left to individual user choice or a domain name holder MAY specify that publication requests be directed to a specific publication service. Users of a public email service are likely to want to insist on their own choice of publication service while a bank or government enterprise that has deployed its own security infrastructure is likely to want to insist that only credentials they approve are accepted for their site.
To allow researchers the widest possible lattitude in developing new trust infrastructures, publication of three trust assertion formats are supported together with support for key backup and recovery. These assertion formats are:
The first time that the Publication Service is used is after the user generates a new keypair.
For example, Alice registers the keypair generated in the previous example with her chosen Publication Service. Her key management tool makes an Assert request to the service with the following information:
Request
{
"AssertRequest": {
"KeyIdentifier": "
AERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keU",
"EncryptedKey": {
"EncryptedPrivateKey": "
MIICeDACBQAEggJwndcAhT3h-6VusVOSxMus5qOJJUP8ewc8fDMTVuNChErVJ_f8
R_LfEhBK8IMPKCHud4RMMGEn9tv5GqXKvElXQlFT--70d27UScOlb28Ciz5MAeZ-
VBokGOnbDPQ_viFGhpq_Mx7fXpPsZGOC2KCxML9Ma1qqgDx34pjrAAdr5SdS2Ky0
x5oYAFJA2hOPOtZN9cgEkC8NdjpLP5sOy_szVbVSeBjh9qL77pkpJvmqAOMz8tjS
XQaw29l160CcvLY-TXswAIiFnY-sNf3ropgQudXqJfNEdXjWPP95Fms3bCbNYwR3
2V50aJve8f55vleNoVA6G11IM8MHZBe3gzHQy0ncrfMzRF9Nl5ayw8K6C6mF0SY4
P_DxU88SrTPBneF1sARWRgIONZRD6-z6TuJLD2H3PqhecKKXpV2NlHnrR93u0NLH
W4_eAamrxp9TcfHGDdktcbYba5P3QnwfaR_XUgg_yofbI8diMmgW17pFnjgyO4C1
4HVlr-pdTzHWF0MOfK1mP5tDxLeIddoIJ5Mo6w3cEKqRTCKuEq79WKdIxFEWMuKn
O-5dYtpW0LjF4vtTIm_rdv5HDeyGOcN6gyo3GLB8Ga2wUCwlO-t8SZ5LfqbqlIZF
rF7mgDYEEeEJodAW_4KznS4EAd9X4uuQ-sMjdp_al_5o8I45jXFnGH2KjMmMkitI
GJr3YPN7lAf_87Xkxw8ktYnzRGCmVIfY_CU_AAFsixHnBYyE_nf9U7Hp6kqietgS
qFs4EDiBVxgMJhuLfswzU9wtlW6UVtDYJftn3NJjryxwUM6mr7-PG86iquYAAAAA
AAAAAAAAAAAAAAAA"},
"Certificate": ["
MIICMDCCAaQAAQICEC9SGLG5FJwVSb5qRQGMdGAwAgUAMAQwAjEAMB4XDTEzMTEw
MTEyMDAwMVoXDTMzMTExNjA1MDA0NFowBDACMQAwgZQwAgUAA4GNADCBiQKBgQDM
Tt6kHdRm_QSTFGN5kZZiNXeBR4VFhcoR_QDxEsZqhw9cMYR71SZDZ_4h3xvBWrtx
uzv9nhHmVAh0RBaU2bPr2JKOdApUSkko_AjKoFMWkwhWej0ey5waWXTnAFvmNckn
mMzQRSkwSMcY3f57f3FogSb_l9xcrlRBorQUdwT9fwIDAQABAQACACOBwTApBgMO
HVUCAQAEHwQdAERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keUwMAYDIx1VAgEA
BCYwJAAdAERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keUBAAIBADAlBgMRHVUC
AQAEGzAZMBcwFQUAFhFhbGljZUBleGFtcGxlLmNvbTAQBgMPHVUCAf8EBgMEAAcA
gDAYBgMlHVUCAQAEDjAMMAoGCAQDBwUFAQYrMA8GAxMdVQIBAAQFMAMCAQAwAgUA
A4GBAApColS86hwM0t2ehZyH1-sXS6kL95WBRquKpdjspok_Bts4Y1sXjgiiu6AY
S9o_Y5vu4-mftgEwiTfhqrh_AJ_FcdD7Mohglo2O8b1lvfLXqoiRjLsAEF79M9A5
UWHf6t-WyaYvu6QBfEvESbvDpzndn3pFGmgjETrAPwZwY4AG"],
"CertificateRequest": ["
MIIBLTCBogIBADAEMAIxADCBlDACBQADgY0AMIGJAoGBAMxO3qQd1Gb9BJMUY3mR
lmI1d4FHhUWFyhH9APESxmqHD1wxhHvVJkNn_iHfG8Fau3G7O_2eEeZUCHREFpTZ
s-vYko50ClRKSSj8CMqgUxaTCFZ6PR7LnBpZdOcAW-Y1ySeYzNBFKTBIxxjd_nt_
cWiBJv-X3FyuVEGitBR3BP1_AgMBAAEAADACBQADgYEApg6BVGJsxnjRAiYTGMp9
QZX00qSOszIy19u0lWbrVaXl7I4Pz7vfDr3i3ZZNYiWOy70iuY6l-FjLlnkEN_ou
ZIjDicxP5lVqJPfmNckDqIm8KcJ9QPCYNZiSSWYQFPk_4PrEn9wYCTMVn2E2kmZV
YfOBXlmrR6shpwmgf32sJyU"],
"Service": [{
"Email": "alice@example.com",
"Name": "smtp.example.com",
"Protocol": "_smtp._tls",
"Port": 587,
"TLS": true},
{
"Email": "alice@example.com",
"Name": "imap.example.com",
"Protocol": "_smtp._tls",
"Port": 993,
"TLS": true}]}}
Response
{
"AssertResponse": {}}
Alice uses several different devices to read her email and she would like to be able to read encrypted emails on all of them. This requires that the private key be installed on each of the devices that she might want to use.
Alice provides either the Key Recovery Passcode or a sufficient number of Key Shares to reconstruct the passcode to the key management tool running on each device. The device then requests recovery of the private key and associated service information:
Request
{
"RecoverRequest": {
"KeyIdentifier": "
AERyCSjgNp85TrwVD5TvGrtx7ZJuVyrG5rM6keU"}}
Response
{
"RecoverResponse": {}}
Providing the service information with the private key allows the key recovery tool to automate configuration of the user's email account on the device if this has not been done already.
Using the key recovery mechanism to support key transport between devices simplifies the initial coding task at the cost of a sub-optimal user experience for the user with a large number of devices in use and/or frequent key updates.
Future versions of the specification may adopt a different approach to key recovery in which each device in which keys are to be installed establishes a device specific keypair which is in turn used to automate the key transport. A key concern in the design of such a scheme being to prevent a weak random number generator on one device causing the private key to be compromised.
Should the private key be lost, the subject be deceased or some other event occur that renders the key no longer servicable, a revocation statement is generated and issued. Such revocation statements use the Revoke request and the key endorsement message format:
Request
{
"RevokeRequest": {}}
Response
{
"RevokeResponse": {}}
From time to time, Alice meets other PPE users and they endorse each other's keys. The AssertRequest is used to submit one or more signed key endorsements:
Request
{
"AssertRequest": {
"Endorsement": ["
MIH5MG8CAQAXDTEzMTEwMTA1MDA0NFoEHQBEcgko4DafOU68FQ-U7xq7ce2Sblcq
xuazOpHlBB0A6_lnsF7kAUEy_oGLvM-BbXuYjLjVJQ5YPMWHHQUAMBkwFzAVMBMF
ABYPYm9iQGV4YW1wbGUuY29tBQAwAgUAA4GBAIrZK5W4Vi9dAk0LPlEMkP5JQxBC
XHUJ5I9gEMithdJvyE0uZTwedhUlG30YEvRJXkizkJUriAIhNdTQU2YpANyICZHF
27CO-I09d2TGOkmbuuadi-QmH9dgdEmRpBWIOmVcF6mXnRRyG8M4cVbetK9TRqwX
NnlHucuKDA_VIAx9"]}}
Response
{
"AssertResponse": {}}
A key endorsement MAY be submitted to the Publication Interface by any party including the signer or the subject.
Register an assertion set.
The Assert transaction is used when a keypair is first created to register the new Key Identifier, Self Signed Certificate and Certificate Signing Request and to request revision of embedded attributes such as the email security policy.
The Assert transaction is also used to request registration of Key Endorsements.
Recover a previously registered encrypted private key file from the service
If the Key Identifier cannot be found or there is no release code associated with the encrypted private key, the transaction is complete after the first response. Otherwise the service returns the status code 'ChallengeResponse' in response to the initial request and the client MUST make a second request in which it establishes proof of knowledge of the release code to complete the transaction.
Publish a revocation meta-assertion
Register an assertion set
At present only a single Key Identifier may be registered per request and no provision is made to link related requests. This is likely to become necessary when different keys are being used for key endorsement, signature, encryption and master purposes.
Response to an assertion registration request.
It may be useful to expand the response to allow the gateway to provide information such as certificates issued in response to the certification request but these will typically require some form of validation and thus be returned asynchronously.
Request recovery of a previously registered encrypted private key.
Respond to a recovery request.
If the encrypted private key associated with the specified Key Identifier has an associated
Regquest revocation of a previously registered key and all related certificates and endorsements.
Note that whil key revocation necessarily entails revocation of all the certificates and endorsement associated with the key, the reverse is not the case. A user may revoke a certificate granting use of a key for encrypted email without wishing to revoke a certificate for the same key granting use for signed email.
Response to revocation request.
I am sure there are some.
Thanks to the many people who have encouraged me in this work and in particular the members of the IETF PERPASS list and the Cryptography mailing list. Future versions of the draft will have a more complete list.
| [I-D.moriarty-pkcs12v1-1] | Moriarty, K., Nystrom, M., Parkinson, S., Rusch, A. and M. Scott, "PKCS 12 v1: Personal Information Exchange Syntax", Internet-Draft draft-moriarty-pkcs12v1-1-01, March 2013. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |