1 TLS Pool Validation Policy
2 ==========================
4 > *How should we validate remote identities? What should we offer to let the
5 > remote validate our local identities? There are quite a few mechanisms.
6 > We’ll enable setting up policies per remote and per local identity.*
8 The following techniques are available (and more will follow, judging from the
9 rope-pulling contest between PKIX and real-life security):
11 - **Chain trust:** based on signatures up to a trusted CA.
13 - **CRL validation:** lookup if a certificate number is revoked. This can be
14 distributed from a central point and matches with our database-driven model.
15 A certificate may also mention a CRL source.
17 - **OCSP validation:** a live variation on CRL validation, although often
18 tuned down by simply spooning out CRL information, but it would permit local
19 overrides. OCSP references from certificates may impose leak certificate
20 usage information and is not advised; OCSP stapling as part of the TLS
21 protocol is being proposed to overcome that. We might consider an explicitly
22 configured OCSP responder under local but central control.
24 - **DANE validation:** a live add-on to the other forms of certificate
25 validation, DANE lists certificates, keys or their fingerprints in DNS. Note
26 that DANE could also be a data source to an OCSP responder. Note that DANE
27 requires additional knowledge about transport protocols and port numbers
28 that are not contained in certificates.
30 - **Global Directory validation:** a live add-on to the other forms of
31 certificate validation, listing certificates in LDAP. This is generally
32 where a remote identity administers the desirability of trust in their
35 - **Pinning:** the storage of a fingerprint of a certificate or key as a
36 returning one for the given remote identity. There may be a limitation to
37 the validity period of pinned identities, resulting from limited validity of
38 the certificate received.
40 - **Forward Secrecy:** the use of a suitable cipher suite ensures that future
41 reverse engineering of a private key does not make stored sessions from the
44 - **Anonymising Precursor:** before embarking on an exchange of keys and
45 identities, wrap a cloak of ANON-DH around the handshake; the parties will
46 immediately renegotiate the actual handshake. This is called an “anonymising
47 precursor” to the TLS handshake. Although it is not commonly done, it helps
48 to conceal the identities on the client and server side. The only situation
49 in which it might be unsafe is if either side starts sending sensitive
50 information before authentication completes; also note that the client must
51 undertake the renegotiation, and that the server may only ask for it. In
52 real-life protocols, this is rarely if ever a problem; most protocols start
53 off with a less sensitive exchange that gives the server an opportunity to
54 wait for authentication to complete.
56 Constraint Enforcement
57 ----------------------
59 It is very much a matter of personal preference what constraints should be
60 fulfilled when validating certificates. Moreover, it may depend on the target.
61 We therefore do the following:
63 - We define a constraint for each local user. To combine them, DoNAI selectors
64 are used. This may be used to constrain trust by this local identity in a
65 remote identity; it may not apply in all situations and will often be set to
66 1 (for True). It is generally useful for additional constraints.
68 - We define a constraint for each remote user. To combine them, DoNAI
69 selectors are used. This may be used to constrain access by those remote
70 identities to any local identity.
72 - **No:** We define a constraint for the client role? No, but we may store it
73 without a `LID_ROLE_SERVER` flag if we insist on treating client and server
76 - **No:** We define a constraint for the server role? No, but we may store it
77 without a `LID_ROLE_CLIENT` flag if we insist on treating client and server
80 - **Perhaps:** We may define a constraint for each trust root. There is no use
81 of DoNAI selectors to combine them. This may be useful to constrain the
82 validation of a client-signing root.
84 These *2 or 3 sources of constraints* for remote ID validation can all be looked
85 up in databases. They are combined to one expression, in such a way that they
88 **NOTE:** Mention of validation expressions in multiple sources is currently
89 not supported; setup either in `localid.db` or `trust.db` to avoid landing
90 the TLS Pool in undefined territory. See
91 [reported issue](https://github.com/arpa2/tlspool/issues/27).
96 **Note:** Not all the predicates defined below have been (completely)
98 [the issue](https://github.com/arpa2/tlspool/issues/29)
99 for up-to-date information.
101 The following constructs are supported; consider them as stack manipulation
104 - `1` pushes a trivially true value onto the stack.
106 - `0` pushes a trivially false value onto the stack.
108 - `L` applies a given level of security settings; `l` applies another level of
109 security settings. Either replaces the default security level. The
110 distinction between these three levels, even their ordering, is a local
113 - `I` and `i` ensure that the remote peer provides an identity, and that it
114 does not contradict the remote identity requested by an application.
115 This will often be used by a local ID that desires to know the remote ID
116 if its counterpart. The remote identity reported back to the application
117 may be enhanced with identity information from the remote certification.
118 The form `I` requires that the domain and username match (where absense
119 of username in both is acceptable) whereas the `i` form permits a
120 remote domain identity to speak on behalf of users underneath that
121 domain without certifying for the username part.
123 - `F` ensures that forward secrecy is employed to protect the connection. This
124 property is only ensured by `TLS_DHE_`, `TLS_ECDHE_`, `TLS_SRP_` and our own
125 `TLS_KDH_` cipher suites. Note that the TLS handshake phase is mostly
126 visible, including the identities exchanged; see `A` and `a` for an
127 alternative that resolves that too. While `F` enforces ephemeral
128 Diffie-Hellman on both ends, `f` will also accept certificate-fixed
129 Diffie-Hellman public keys on one of the ends.
131 - `A` enforces, and `a` attempts the use of an anonymising precursor to
132 conceal the actual handshake, and any identities contained in it. Since most
133 TLS stacks do not implement ANON-DH as a precursor, requiring the
134 anonymising precursor is currently of limited use; it should work mostly
135 when the TLS Pool is known to run remotely. Although a server can withhold
136 identities when it chooses to start with ANON-DH, a client has a slight
137 disadvantage; it cannot refrain from sending identities that are expected in
138 the ClientHello, notably the Server Name Indication, when `a` is used, but
139 it may do that when `A` is used.
141 - `T` validates trust based on a trusted certificate/key list. For X.509 this
142 means that a path to a root certificate is needed; for OpenPGP it means that
143 the trust base needs to establish some path to the key. The outcome is
144 pushed onto the stack. The variation `t` will also push a positive outcome
145 for self-signed certificates, thus ensuring through X.509 mechanisms that
146 the certificate as a whole was issued by the private key owner; it is
147 uncommon to trust `t` without other validation mechanisms like the ones
148 described under `D`, `G` and `P`.
150 - `D` and `d` verify through DNSSEC. For X.509, DANE’s `TLSA` records are
151 investigated; for OpenPGP, `CERT` records are considered. The variation `D`
152 requires presence of the information, while `d` will also accept verifiable
153 denial of the information or DNSSEC opt-out for their DNS entries, meaning
154 that DNSSEC assures the absense of the records. Note that DNSSEC entries are
155 only advised for hosts; for individual reasons, the Global Directory is
156 preferred for reasons of privacy and accurate definitions.
158 - `R` verifies through lists of certificate revocations; for X.509 this means
159 that CRLs are investigated; for OpenPGP it means the same as `G`. The
160 variation `r` also accepts confirmed absense of a CRL for X.509, or acts
161 like `g` for OpenPGP. The outcome is pushed onto the stack.
163 - `E` and `e` evaluate certificate extension expressions. Where `E` only
164 requires required-critical OIDs to indeed be marked critical in the remote
165 peer credential, `e` will also accept those in the peer’s non-critical
166 extensions. The set of OIDs to be considered are configured on a
167 per-service-name basis and these are compiled into the TLS Pool; each is
168 either critical (which is only enforced by `E`) or non-critical (which means
169 that `E` won't require it to be a critical extension either). It is not an
170 error if a non-critical extension turns up in a credential as a critical
173 - `O` and `o` validate online/live information; for X.509 this means that a
174 predefined OCSP central responder under local management is being contacted;
175 for OpenPGP `O` means the same as `G` and `o` means the same as `g`. Where
176 `O` for X.509 requires the outcome to be `good`, the outcome of `o` may also
177 be `unknown`. The outcome is pushed onto the stack.
179 - `G` and `g` incorporate Global Directory information; for X.509 this means
180 that a directory lookup is made for the SubjectDN, assuming it ends in
181 `dc=,dc=` format and otherwise interpreting a domain name from an
182 `emailAddress` or a `commonName` that looks like a domain name or a
183 `dnsName` alternate name; for OpenPGP it means that the key’s own revocation
184 information is verified in a key's directory entry. Where `G` requires the
185 presence of a certificate in the Global Directory, `g` will also accept
186 verified denial of the information or DNSSEC opt-out for their DNS entries.
187 The outcome is pushed onto the stack. Note that the Global Directory is
188 gentler than DNSSEC entries for individual users because it is more
189 accurately defined, and because more control over user privacy is possible.
191 - `P` and `p` look at locally stored pinning information, and checks whether
192 it resembles the current certificate; for X.509, this means looking up a
193 certificate fingerprint to match a pinned identity when it has not expired
194 yet; for OpenPGP, this means looking up a public key fingerprint to match a
195 pinned identity when it has not expired yet. The variation `P` fails hard
196 when the pinning information is absent, whereas `p` will accept it silently
197 upon first encountering it when there is nothing else pinned. It depends on
198 local policy whether `p` on its own is considered secure (TOFU-style) or
199 should be combined with another form of authentication, such as `D`, `G` or
202 - `U` requires a match of the username with the form of identification. By
203 default, it is assumed that a certificate for a domain name can act on
204 behalf of any user of that domain; this is usually a sensible default
205 because domains should act on behalf of their users. Note that username
206 mismatches are never acceptable; one user cannot act on behalf of another
207 user; the default case merely permits a certificate for a domain without
208 username to act on behalf of all users situated under that domain. So, in
209 fact, this requirement comes down to simply adding the requirement that a
210 username is present in the remote ID if it is to represent a user. TODO:
211 Consider adding `u` for…? perhaps to try to find a username, but possibly
212 accept a hostname only. Default behaviour with neither is then to only take
215 - `S` and `s` select the situation where the local TLS protocol side acts as a
216 server; `S` additionally ensures that it uses a certificate marked in the
217 local identity database just for server use (that is, `S` suppresses
218 peer-to-peer validation and `s` permits it).
220 - `C` and `c` select the situation where the local TLS protocol side acts as a
221 client; `C` additionally ensures that it uses a certificate marked in the
222 local identity database just for client use (that is, `C` suppresses
223 peer-to-peer validation and `c` permits it).
225 - `&` combines the top two stack entries through conjunction.
227 - `|` combines the top two stack entries through disjunction.
229 - `~` replaces the top stack item with its logical inverse.
231 - `?` removes the top stack item; if it is true, it keeps the second but
232 removes the third; otherwise it keeps the third but removes the second.
234 These operations are implemented as lazily as possible, of course. Checks may be
235 mentioned more than once without them actually being computed over and over
238 The outcome of the operations is usually one of four states: `uncomputed`,
239 `positive`, `negative` or `absent`. At least the `positive` and `absent`
240 outcomes must be verifiable to stop any attacks. Note how usually the lowercase
241 letter stands for a weaker version of the uppercase letter; that is, uppercase
242 =\> lowercase. Indeed, the various checks may learn from each other.
244 **Syntax.** A correct expression is one that leaves a single expression on the
245 stack. In addition, it is not permitted to remove undefined values from the
246 stack. A simple check can validate these properties.
248 **Bit-code semantics.** *Not true, we need two levels of NAND:* A compact
249 storage form is a sequence of bit fields. The sequence expresses the top-level
250 `&` and within the bit field is the `|` with variations with and without `~` per
251 bit; each bit represents one of the letters/digits above. This does not answer
252 to the `?` operator, or otherwise it does it indirectly. Such structures can be
253 evaluated efficiently, because it can quickly be determined what the minimum
254 effort is. The value `1` can be most compactly represented in an empty list.
255 *Additional idea:* x?y:z == xy&x\~z&\|yz&\| — the yz& case being an unexpected
258 **Combining constraints.** As stated, the local and remote ID as well as
259 (perhaps) a trust root may give rise to constraints. Each of these must
260 independently pass the syntax check. Note that both check the remote ID
261 validity. The two are run in sequence and then `&` is run to combine them. More
262 constraints may be added, each followed by an `&` operation. Or, in terms of the
263 semantics, the sequences are (considered) concatenated. Many local ID
264 expressions will simply be `1` to avoid running any logic.
266 **Example.** A typical configuration for “proper” certificate verification would
269 - Require a chain of trust
271 - Validate CRL or OCSP
273 - Validate DANE or Global Directory
275 This would be formulated as `TCO|DG|&&` or, equivalently, `TCO|&DG|&`
277 **Example.** Another typical configuration could be a reasonably reliable
278 “self-signed” format:
280 - Do not require a chain of trust
282 - Validate pinning or DANE or Global Directory
284 This would be formulated as `PDG||` or, equivalently, `PD|G|`
289 Some of the validation schemes may require parameters. These parameters are set
290 separately, because they may not be proper at the places where the constraint
293 - **X.509 Root CAs.** These are used as trust anchors when performing X.509
294 certificate chain validation. It is stored in the trust database.
296 - **OpenPGP Trusted Keys.** These are considered trusted signers. It should
297 currently be setup to support no intermediate keys, so there need not be Web
298 of Trust evaluations. This key list is stored in the trust database.
300 - **OCSP Responder.** This points to an OCSP responder, usually under local
301 control, together with the public key that it uses to sign responses. It is
302 stored in the trust database.
304 - **Local Directory.** This references an LDAP repository that enhances,
305 filters and generally overlays the Global Directory to form a local access
306 path to it; it may be used for local adaptions to what is published to the
307 Internet, or it may be used to make references from an `o=,c=` LDAP root to
308 a `dc=,dc` alias. This is stored in the trust database.
310 - **Extension OIDs.** These are set per service type. They are stored in the
311 trust database. The options `E` and `e` look at these values. Each extension
312 OID is set to be either critical or non-critical. The textual format is
313 `OID` for non-critical, and `OID!` for critical extensions; values are not
314 defined for now, but may add something like `=...` to the format in future
315 versions. Verifications can be composed with `&` and `|` postfix operators;
316 there is no negation or other logic complexity. The database may use a
317 binary format based on the RFC 5280 definition of `Extension`, which
318 includes a value (to be set empty) and a `CRITICAL` flag; the logic
319 constructs will be captured by placing `&` compositions in a `SEQUENCE` and
320 `|` compositions in a `SET`, using De Morgan to limit everything to two
323 - **Key Sizes.** These are defined for each permitted algorithm, and used to
324 select appropriate cipher suites. They are stored in the trust database. We
325 permit two security levels, e.g. reflected in an `L` and `l` command, and
326 set values for each separately; in addition, there is a nothing-said default
327 security level. It is up to the local policy settings what the
328 interpretation of the default, `l` and `L` levels are. Note that some
329 algorithms may be banned from one security level only.
331 Anticipated Use Cases
332 ---------------------
334 Below, we write `=>` for database mappings, `key => value` and we use [DoNAI
335 selectors](<http://donai.arpa2.net/selector.html>) as keys because we match
336 against a remote identity in [DoNAI](<http://donai.arpa2.net>) form.
338 It is expected that a public service, such as a website, will set its default
339 formula for local identities straightforwardly to
341 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
344 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
346 but override it for local sites that require certificate login to something
349 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
350 my.example.com => TCO|DH|&&
351 @example.com => PDG||
352 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
354 On the other hand, a typical client's default setting for remote ID will be more
355 stringent, for instance
357 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
360 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
362 and in this case overrides may actually be lenient on specially selected
365 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
366 befriended.example.org => PDG||
367 @befriended.example.org => PDG||
368 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
370 Which will let friends in on grounds of pinned identities and a few methods to
371 bootstrap it under their own control. We’re only trusting that on top of basic
372 certificate validity for the more general case of remote identities. Note that
373 no effort is made to validate the certificate’s (self-)signature. Had we wanted
374 that, we could have added `t&` at the ends of the formulæ given.
376 Finally, a wilder example; a server might employ a certificate with a trivial
377 RSA signature (for example: modulus `0x01` always gives signature value `0x00`)
378 but have the total certificate protected through one of the other means (DANE,
379 Global Directory, Pinning) and it might mention a fixed Diffie-Hellman public
380 key. The server side cannot participate in forward secrecy, but the client may
381 still toss in enough random material to obtain a session key with the property.
382 Such a wild configuration might be approved with
384 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
385 wild-demo.example.org => PDG||F&
386 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
388 This example is actually more stringent than the average self-signed certificate
389 proposal; the additional requirement of forward secrecy might of course be
390 applied to those as well; the only thing “wild” about this example is the form
391 of the certificate, where the signature is ignored and thus setup with a really
394 Note that clients and servers vary in which of the identities is present. A
395 server may welcome anything, which is reflected by the default assumption that
396 the local identity is not constrained, but the remote identity is if it exists.
398 Servers acting after-the-fact
399 -----------------------------
401 TLS being what it is, servers do not know the client identity before they choose
402 a cipher suite; the only thing they may know is their own local identity. This
403 means that, different from the examples above, a server may need to set more
404 stringent validation expressions when they are known to act as a server. Note
405 that the settings will be reloaded once the client identity is known, and they
406 will be applied; but at that time, a server may be stuck to a choice that it
407 made in an earlier phase, and that it rejects in the later phase.
409 To support a solution in this area, the commands `S` and `s` have been created,
410 together with their mirror images `C` and `c`. These can be used to be more
411 demanding on servers, for example for the local default names.
413 Interactive configuration tools, such as web interfaces, should perhaps warn
414 when this kind of problem is likely to occur. They can do this by comparing
415 server settings at different levels of abstraction — such as a concrete name and
projects / tlspool / blob