]>
Commit | Line | Data |
---|---|---|
cec3901a P |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
5 | property - Properties, a selection mechanism for algorithm implementations | |
6 | ||
7 | =head1 DESCRIPTION | |
8 | ||
9 | As of OpenSSL 3.0, a new method has been introduced to decide which of | |
10 | multiple implementations of an algorithm will be used. | |
11 | The method is centered around the concept of properties. | |
12 | Each implementation defines a number of properties and when an algorithm | |
13 | is being selected, filters based on these properties can be used to | |
14 | choose the most appropriate implementation of the algorithm. | |
15 | ||
16 | Properties are like variables, they are referenced by name and have a value | |
17 | assigned. | |
18 | ||
19 | =head2 Property Names | |
20 | ||
21 | Property names fall into two categories: those reserved by the OpenSSL | |
22 | project and user defined names. | |
23 | A I<reserved> property name consists of a single C-style identifier | |
24 | (except for leading underscores not being permitted), which begins | |
25 | with a letter and can be followed by any number of letters, numbers | |
26 | and underscores. | |
27 | Property names are case-insensitive, but OpenSSL will only use lowercase | |
28 | letters. | |
29 | ||
30 | A I<user defined> property name is similar, but it B<must> consist of | |
31 | two or more C-style identifiers, separated by periods. | |
32 | The last identifier in the name can be considered the 'true' property | |
33 | name, which is prefixed by some sort of 'namespace'. | |
34 | Providers for example could include their name in the prefix and use | |
35 | property names like | |
36 | ||
37 | <provider_name>.<property_name> | |
38 | <provider_name>.<algorithm_name>.<property_name> | |
39 | ||
40 | =head2 Properties | |
41 | ||
42 | A I<property> is a I<name=value> pair. | |
43 | A I<property definition> is a sequence of comma separated properties. | |
44 | There can be any number of properties in a definition. | |
45 | For example: "" defines a null property definition; "my.foo=bar" | |
46 | defines a property named I<my.foo> which has a string value I<bar> and | |
47 | "iteration.count=3" defines a property named I<iteration.count> which | |
48 | has a numeric value of I<3>. | |
49 | The full syntax for property definitions appears below. | |
50 | ||
51 | =head2 Implementations | |
52 | ||
53 | Each implementation of an algorithm can define any number of | |
54 | properties. | |
55 | For example, the default provider defines the property I<default=yes> | |
56 | for all of its algorithms. | |
57 | Likewise, the FIPS provider defines I<fips=yes> and the legacy provider | |
58 | defines I<legacy=yes> for all of their algorithms. | |
59 | ||
60 | =head2 Queries | |
61 | ||
62 | A I<property query clause> is a single conditional test. | |
63 | For example, "fips=yes", "default!=yes" or "?iteration.count!=3". | |
64 | The first two represent mandatory clauses, such clauses B<must> match | |
65 | for any algorithm to even be under consideration. | |
66 | The third clause represents an optional clause. | |
67 | Matching such clauses is not a requirement, but any additional optional | |
68 | match counts in favor of the algorithm. | |
69 | More details about that in the B<Lookups> section. | |
70 | A I<property query> is a sequence of comma separated property query clauses. | |
71 | The full syntax for property queries appears below. | |
72 | ||
73 | =head2 Lookups | |
74 | ||
75 | When an algorithm is looked up, a property query is used to determine | |
76 | the best matching algorithm. | |
77 | All mandatory query clauses B<must> be present and the implementation | |
78 | that additionally has the largest number of matching optional query | |
79 | clauses will be used. | |
80 | If there is more than one such optimal candidate, the result will be | |
81 | chosen from amongst those in an indeterminate way. | |
82 | Ordering of optional clauses is not significant. | |
83 | ||
84 | =head2 Shortcut | |
85 | ||
86 | In order to permit a more concise expression of boolean properties, there | |
87 | is one short cut: a property name alone (e.g. "default") is | |
88 | exactly equivalent to "default=yes" in both definitions and queries. | |
89 | ||
90 | =head1 Syntax | |
91 | ||
92 | The lexical syntax in EBNF is given by: | |
93 | ||
94 | Definition ::= PropertyName ( '=' Value )? | |
95 | ( ',' PropertyName ( '=' Value )? )* | |
96 | Query ::= PropertyQuery ( ',' PropertyQuery )* | |
97 | PropertyQuery ::= '-'? PropertyName | |
98 | | '?'? ( PropertyName (( '=' | '!=' ) Value)?) | |
99 | Value ::= NumberLiteral | StringLiteral | |
100 | StringLiteral ::= QuotedString | UnquotedString | |
101 | QuotedString ::= '"' [^"]* '"' | "'" [^']* "'" | |
102 | UnquotedString ::= [^{space},]+ | |
103 | NumberLiteral ::= '0' ( [0-7]* | 'x' [0-9A-Fa-f]+ ) | '-'? [1-9] [0-9]+ | |
104 | PropertyName ::= [A-Z] [A-Z0-9_]* ( '.' [A-Z] [A-Z0-9_]* )* | |
105 | ||
106 | Railroad diagrams for this grammar can be found in the | |
107 | F<crypto/property/properties.xhtml> file. | |
108 | ||
109 | =head1 HISTORY | |
110 | ||
111 | Properties were added in OpenSSL 3.0 | |
112 | ||
113 | =head1 COPYRIGHT | |
114 | ||
115 | Copyright 2019 The OpenSSL Project Authors. All Rights Reserved. | |
116 | ||
117 | Licensed under the Apache License 2.0 (the "License"). You may not use | |
118 | this file except in compliance with the License. You can obtain a copy | |
119 | in the file LICENSE in the source distribution or at | |
120 | L<https://www.openssl.org/source/license.html>. | |
121 | ||
122 | =cut |