Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track October 27, 2014
Expires: April 30, 2015
PRISM_Proof Email Key Generation and Publication
draft-hallambaker-prismproof-key-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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."
Copyright Notice
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.
April 30, 2015 [Page 1]
Internet-Draft PPE: Key Generation & Publication October 2014
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Legacy Infrastructure . . . . . . . . . . . . . . . . . . 3
2. Key Generation and Identification . . . . . . . . . . . . . . 3
2.1. Strong Key Identifier . . . . . . . . . . . . . . . . . . 3
2.1.1. Strong Email Addresses . . . . . . . . . . . . . . . 4
2.2. Private Key Backup and Controlled Recovery . . . . . . . 6
2.2.1. Encrypted Private Key . . . . . . . . . . . . . . . 7
2.2.2. Key Splitting . . . . . . . . . . . . . . . . . . . 7
2.3. Private Key Example . . . . . . . . . . . . . . . . . . . 7
2.3.1. Key Identifier . . . . . . . . . . . . . . . . . . . 8
2.3.2. Private Key Backup . . . . . . . . . . . . . . . . . 8
3. Public Key Infrastructure . . . . . . . . . . . . . . . . . . 10
3.1. Certificate Signing Request. . . . . . . . . . . . . . . 11
3.2. Self-Signed Certificate. . . . . . . . . . . . . . . . . 11
3.3. Peer Endorsement . . . . . . . . . . . . . . . . . . . . 11
4. Publication Service . . . . . . . . . . . . . . . . . . . . . 13
4.1. Initial Key Publication . . . . . . . . . . . . . . . . . 14
5. Registration Example . . . . . . . . . . . . . . . . . . . . . 14
5.1. Enabling a new Device . . . . . . . . . . . . . . . . . . 16
6. Recovery Example . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17
7. Revocation Example . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Key Endorsement . . . . . . . . . . . . . . . . . . . . . 17
8. Endorsement Example . . . . . . . . . . . . . . . . . . . . . 17
9. OmniAssertBroker . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. OmniAssertBroker Transactions . . . . . . . . . . . . . . 18
9.1.1. Assert . . . . . . . . . . . . . . . . . . . . . . . 18
9.1.2. Recover . . . . . . . . . . . . . . . . . . . . . . 18
9.1.3. Revoke . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. OmniAssertBroker Messages . . . . . . . . . . . . . . . . 19
9.2.1. Message: AssertRequest . . . . . . . . . . . . . . . 19
9.2.2. Message: AssertResponse . . . . . . . . . . . . . . 19
9.2.3. Message: RecoverRequest . . . . . . . . . . . . . . 19
9.2.4. Message: RecoverResponse . . . . . . . . . . . . . . 20
9.2.5. Message: RevokeRequest . . . . . . . . . . . . . . . 20
9.2.6. Message: RevokeResponse . . . . . . . . . . . . . . 21
9.3. OmniAssertBroker Structures . . . . . . . . . . . . . . . 21
9.3.1. Structure: Service . . . . . . . . . . . . . . . . . 21
9.3.2. Structure: EncryptedKey . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
April 30, 2015 [Page 2]
Internet-Draft PPE: Key Generation & Publication October 2014
1. Problem Statement
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
1.1. Legacy Infrastructure
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.
2. Key Generation and Identification
2.1. Strong Key Identifier
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.
April 30, 2015 [Page 3]
Internet-Draft PPE: Key Generation & Publication October 2014
A strong Key Identifier takes one of the two following forms:
If the length of the Key Identifier is exactly 20 octets.
The Key Identifier is an OpenPGP v4 Key fingerprint calculated
as specified in [!RFC4880]
Otherwise
The first byte specifies the digest algorithm and the following
bytes the digest value calculated over the DER encoded
SubjectPublicKeyInfo.
The following algorithm values are assigned in this document:
0
SHA-2-512 truncated to 128 bits.
1
SHA-2-512 truncated to 224 bits.
2
SHA-2-512 truncated to 256 bits.
3
SHA-2-512 without truncation
128-255
Reserved for use in a future multi-byte algorithm identifier
scheme.
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.
2.1.1. Strong Email Addresses
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.
April 30, 2015 [Page 4]
Internet-Draft PPE: Key Generation & Publication October 2014
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
April 30, 2015 [Page 5]
Internet-Draft PPE: Key Generation & Publication October 2014
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:
nokey
Messages sent to the address MUST be encrypted under an
encryption key that the sender determines to be trustworthy.
direct-key
If the public key specified by the Key Identifier is an
encryption key, messages sent to the address MUST be encrypted
under the specified key. Otherwise messages sent to the address
MUST be encrypted under an encryption key that has a direct key
endorsement under the specified key.
indirect-key
Messages sent to the address MUST be encrypted under an
encryption key that has a key endorsement under the specified
key.
2.2. Private Key Backup and Controlled Recovery
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.
April 30, 2015 [Page 6]
Internet-Draft PPE: Key Generation & Publication October 2014
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.
2.2.1. Encrypted Private Key
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.
2.2.2. Key Splitting
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.
2.3. Private Key Example
Alice uses a key generation tool to generate a public keypair. The
public parameters in hexadecimal are:
April 30, 2015 [Page 7]
Internet-Draft PPE: Key Generation & Publication October 2014
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
2.3.1. Key Identifier
KeyIdentifier: ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA
alice@example.com
Send email to Alice using encryption if and only if an
encryption key for Alice can be found and Alice has published
the email encryption policy 'encryption preferred' or stronger.
?alice@example.com
Send email to Alice using encryption if and only if an
encryption key for Alice can be found, otherwise report an
error.
ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-
DAA?alice@example.com
Send email to Alice using encryption if and only if an
encryption key for Alice can be found that is directly endorsed
under the specified key, otherwise report an error.
ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-
DAA??alice@example.com
Send email to Alice using encryption if and only if an
encryption key for Alice can be found that is (directly or
indierectly) endorsed under the specified key, otherwise report
an error.
April 30, 2015 [Page 8]
Internet-Draft PPE: Key Generation & Publication October 2014
2.3.2. Private Key Backup
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
April 30, 2015 [Page 9]
Internet-Draft PPE: Key Generation & Publication October 2014
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
3. Public Key Infrastructure
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:
A Certificate Signing Request
May be presented to a CA or other signer.
April 30, 2015 [Page 10]
Internet-Draft PPE: Key Generation & Publication October 2014
A self signed certificate
Presents the public key in a form that many Internet
applications accept directly.
3.1. Certificate Signing Request.
Certificate Signing Requests SHOULD conform to the following profile:
* The Key Identifier MUST be specified and MUST be a strong key
identifier
* [[Prohibit various PKIX lunacies]
3.2. Self-Signed Certificate.
Self Signed Certificates SHOULD conform to the following profile:
* The Key Identifier MUST be specified and MUST be a strong key
identifier
* [[Prohibit various PKIX lunacies]
3.3. Peer Endorsement
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
April 30, 2015 [Page 11]
Internet-Draft PPE: Key Generation & Publication October 2014
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:
April 30, 2015 [Page 12]
Internet-Draft PPE: Key Generation & Publication October 2014
Direct Endorsement
A endorsement of a user's key identifier by another key held by
the same user. This form of endorsement allows a user to
establish a personal master key that is only used for the
purpose of endorsing keys for specific uses (email encryption,
email signature, endorsement, etc.)
Peer Endorsement
A user endorses the key identifier of another user (the
subject) and possibly other aspects of the subject's identity
such as their name, likeness etc. Such an endorsement SHOULD
specify the basis for the endorsement (in person, remote,
recent acquaintance, verification of government documents,
childhood friend, etc.)
Group Endorsement
One of the use practices that has emerged from attempts to
employ PGP is the 'key party' in which groups of users perform
mutual keysigning.
Withdrawing an Endorsement
In certain circumstances, it MAY be necessary to withdraw an
endorsement. The reason for withdrawing the endorsement SHOULD
be specified in the UnEndorsement notice and MAY include,
notification of the loss of the private key, the subject is
deceased, etc.)
4. Publication Service
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.
April 30, 2015 [Page 13]
Internet-Draft PPE: Key Generation & Publication October 2014
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:
Self Signed Certificate
A PKIX self signed certificate which MAY be used in conjunction
with an existing application that accepts public key
information in self signed certificate form.
Certificate Signing Request
A PKCS#10 Certificate Signing Request conforming to [!RFC2986].
A publication interface MAY forward the Certificate Signing
request to a Certificate Authority for issue of a PKIX end
entity certificate.
Key Endorsement
A Key Endorsement in the format described in this document.
4.1. Initial Key Publication
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:
* The Strong Key Identifier
* The Encrypted Private Key
* A Self-Signed Certificate
* A Signed Certificate Signing Request
* Service information describing the email service parameters to
be used when sending messages using the corresponding email
account. [[Which really should be encrypted, shouldn't they?]
April 30, 2015 [Page 14]
Internet-Draft PPE: Key Generation & Publication October 2014
5. Registration Example
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,
April 30, 2015 [Page 15]
Internet-Draft PPE: Key Generation & Publication October 2014
"TLS": true},
{
"Email": "alice@example.com",
"Name": "imap.example.com",
"Protocol": "_smtp._tls",
"Port": 993,
"TLS": true}]}}
Response
{
"AssertResponse": {}}
5.1. Enabling a new Device
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:
6. Recovery Example
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.
April 30, 2015 [Page 16]
Internet-Draft PPE: Key Generation & Publication October 2014
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.
6.1. Revocation
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:
7. Revocation Example
Request
{
"RevokeRequest": {}}
Response
{
"RevokeResponse": {}}
7.1. Key Endorsement
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:
8. Endorsement Example
Request
{
"AssertRequest": {
"Endorsement": ["
MIH5MG8CAQAXDTEzMTEwMTA1MDA0NFoEHQBEcgko4DafOU68FQ-U7xq7ce2Sblcq
xuazOpHlBB0A6_lnsF7kAUEy_oGLvM-BbXuYjLjVJQ5YPMWHHQUAMBkwFzAVMBMF
ABYPYm9iQGV4YW1wbGUuY29tBQAwAgUAA4GBAIrZK5W4Vi9dAk0LPlEMkP5JQxBC
XHUJ5I9gEMithdJvyE0uZTwedhUlG30YEvRJXkizkJUriAIhNdTQU2YpANyICZHF
27CO-I09d2TGOkmbuuadi-QmH9dgdEmRpBWIOmVcF6mXnRRyG8M4cVbetK9TRqwX
NnlHucuKDA_VIAx9"]}}
April 30, 2015 [Page 17]
Internet-Draft PPE: Key Generation & Publication October 2014
Response
{
"AssertResponse": {}}
A key endorsement MAY be submitted to the Publication Interface by
any party including the signer or the subject.
9. OmniAssertBroker
9.1. OmniAssertBroker Transactions
9.1.1. Assert
* Request: AssertRequest
* Response: AssertResponse
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.
9.1.2. Recover
* Request: RecoverRequest
* Response: RecoverResponse
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.
9.1.3. Revoke
* Request: RevokeRequest
* Response: RevokeResponse
April 30, 2015 [Page 18]
Internet-Draft PPE: Key Generation & Publication October 2014
Publish a revocation meta-assertion
9.2. OmniAssertBroker Messages
9.2.1. Message: AssertRequest
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.
KeyIdentifier :
Binary [1..1] Strong Key Identifier formed using a message
digest function over the DER encoded Public Key Info block.
EncryptedKey :
EncryptedKey [0..1] Encrypted Private Key and associated
attributes.
Certificate :
Binary [0..Many] PKIX Certificates to be registered, comply
with [!RFC5280] and additional profile constraints specified
here.
CertificateRequest :
Binary [0..Many] Certificate Request in [!RFC2986] format.
Endorsement :
Binary [0..Many] Key Endorsements as specified in this
document.
Service :
Service [0..Many] Service connection information for associated
services. For example, email IMAP [!RFC3501], POP3 [!RFC5034]
and SUBMIT [!RFC4409] accounts.
9.2.2. Message: AssertResponse
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.
April 30, 2015 [Page 19]
Internet-Draft PPE: Key Generation & Publication October 2014
9.2.3. Message: RecoverRequest
Request recovery of a previously registered encrypted private key.
KeyIdentifier :
Binary [1..1] Key Identifier of key pair for which recovery of
the private key is being requested.
Challenge :
Binary [0..1] Client challenge value for proof of knowledge of
the release code.
Answer :
Binary [0..1] Answer value for proof of knowledge of the
release code.
9.2.4. Message: RecoverResponse
Respond to a recovery request.
If the encrypted private key associated with the specified Key
Identifier has an associated
EncryptedPrivateKey :
Binary [0..1] PKCS#8 Encrypted Private Key as specified in
[!RFC5208].
Challenge :
Binary [0..1] Server challenge value for proof of knowledge of
the release code.
Algorithm :
String [0..1] Digest algorithm for proof of knowledge of the
release code.
9.2.5. Message: RevokeRequest
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.
KeyIdentifier :
Binary [1..1] Key Identifier of Key to be revoked.
April 30, 2015 [Page 20]
Internet-Draft PPE: Key Generation & Publication October 2014
Notice :
Binary [0..1] Signed Key Endorsement object with the 'revoke'
attribute specified.
9.2.6. Message: RevokeResponse
Response to revocation request.
9.3. OmniAssertBroker Structures
9.3.1. Structure: Service
Email :
String [0..1] Principal Email address associated with the
account
OtherEmail :
String [0..Many] Additional Email addresses associated with the
account.
Name :
String [0..1] DNS Address of Service
Protocol :
String [0..1] SRV format protocol identification prefix.
Port :
Integer [0..1] IP Port number
TLS :
Boolean [0..1] If true, use of TLS is required
Security :
String [0..1] Security policy description
9.3.2. Structure: EncryptedKey
EncryptedPrivateKey :
Binary [1..1] PKCS#8 Encrypted Private Key as specified in
[!RFC5208].
PFX :
Binary [0..1] PKCS#12 Encrypted Private Key as specified in
[!~I-D.moriarty-pkcs12v1-1].
ReleaseCode :
Binary [0..1] Release Code value for authorizing private key
recovery requests. If specified the service MUST NOT release
the encrypted private key unless the requestor satisfies a
challenge-response request that establishes knowledge of the
Release Code.
April 30, 2015 [Page 21]
Internet-Draft PPE: Key Generation & Publication October 2014
10. Security Considerations
I am sure there are some.
11. Acknowledgments
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.
12. References
12.1. Normative References
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley,
R.,Polk, W., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC2986] Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request
Syntax Specification Version 1.7", RFC 2986, November
2000.
[~I-D.moriarty-pkcs12v1-1] , "[Reference Not Found!]".
[RFC4409] ,Gellens, R.,Klensin, J., "Message Submission for Mail",
RFC 4409, April 2006.
[RFC5034] Siemborski, R.,Menon-Sen, A., "The Post Office Protocol
(POP3) Simple Authentication and Security Layer (SASL)
Authentication Mechanism", RFC 5034, July 2007.
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Private-Key Information Syntax Specification Version 1.2",
RFC 5208, May 2008.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC4880] Callas, J.,Donnerhacke, L.,Finney, H.,Shaw, D.,Thayer, R.,
"OpenPGP Message Format", RFC 4880, November 2007.
[I-D.hallambaker-prismproof-trust] Hallam-Baker, P, "PRISM Proof
Trust Model", Internet-Draft draft-hallambaker-prismproof-
trust-00, 16 October 2013.
April 30, 2015 [Page 22]
Internet-Draft PPE: Key Generation & Publication October 2014
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5869] Krawczyk, H.,Eronen, P., "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010.
12.2. Informative References
[I-D.moriarty-pkcs12v1-1] Moriarty, K,Nystrom, M,Parkinson, S,Rusch,
A,Scott, M, "PKCS 12 v1: Personal Information Exchange
Syntax", Internet-Draft draft-moriarty-pkcs12v1-1-01, 25
March 2013.
[RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter,
L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999.
[RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
April 30, 2015 [Page 23]