You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Fixes for threading.
* Added libwolfkeymgr for general use API's.
* Added ETSI client API's
* Added full HTTP server/client support.
* Abstraction of all modules to library for generic socket, TLS, HTTP and ETSI functions.
* Added non-blocking support for client.
* Added version header
* Improvement to performance.
a) `fingerprints` shall be present and its value, `[fingerprints]`, shall be either empty or shall be a comma-separated list of the hexadecimal string representation where each entry in the list is the static Diffie-Hellman public key fingerprint, as defined in clause 4.3.3, for which the corresponding public/private key pairs are being requested.
51
-
52
-
b) The key manager shall return a key package that contains the corresponding public/private key pair for each fingerprint for which it has a record. In the unlikely case that the key manager has more than one public/private key pair corresponding to a given fingerprint, it shall return all of them in the key package. If `[fingerprints]` is empty, the actions of the implementation are out of scope of the present document.
53
-
54
-
c) The key manager shall return an appropriate HTTP error code if there is not at least one matching public/private key pair [12].
55
-
56
-
Example:
57
-
58
-
```
59
-
GET /.well-known/enterprise-transport-security/keys?fingerprints=00010203040506070809,09080706050403020100
a) `groups` shall be non-empty and its value, `[groups]`, shall be a comma-separated list where each entry in the list is a NamedGroup value defined in clause 4.2.7 in IETF RFC 8446 [2], represented in hexadecimal notation, for which an associated static Diffie-Hellman key pair is being requested.
68
-
69
-
b) `certs` may be included. If certs is included, its value, `[sigalgs]`, shall be a comma-separated list where each entry is a colon-separated pair of SignatureScheme values defined in clause B.3.1.3 in IETF RFC 8446 [2], in hexadecimal notation. The first value in the pair shall indicate the requested algorithm for the certificate issuer to use to sign the certificate. The second value in the pair shall indicate the requested algorithm to be used to generate the certificate subject's signing key pair. If certs is included, then for each entry in the list, the key consumer shall request one additional server certificate using that scheme, which is bound to all returned key pairs. If certs is not included, then no certificates are being requested, and so none shall be provided by the key manager.
70
-
71
-
c) `context` may be included. If `context` is included, its value, contextstr, is a free string that the key manager shall use to determine what key pair and certificate contents to return. The structure of contextstr is not specified in the present document.
72
-
73
-
d) The key manager shall return a key package containing a static Diffie-Hellman key pair for each group listed in `[groups]` that the key manager supports. For each static Diffie-Hellman key pair in the key package, the key manager shall also return a corresponding server certificate for each given signature algorithm pair listed in `[sigalgs]` that it supports.
74
-
75
-
e) If no group in `[groups]` is supported by the key manager, the key manager shall return an appropriate HTTP error code as defined in clause 6 of IETF RFC 7231 [12]. If the key manager is unable to use contextstr, the key manager may return an appropriate HTTP error code, as defined in clause 6 of IETF RFC 7231 [12], or it may handle the error itself in a way outside the scope of the present document.
76
-
77
-
Example:
78
-
79
-
```
80
-
GET /.well-known/enterprise-transport-security/keys?groups=0x0018,0x001d&certs=0x0401:0x0809,0x0503:0x0503
81
-
Accept: application/pkcs8
82
-
```
83
-
84
-
### ETSI Push (HTTPS PUT)
85
-
86
-
The key consumer shall support receiving a key package via an HTTP PUT request to a request-target, given here in origin-form, of `/enterprise-transport-security/keys`.
87
-
88
-
89
-
## Asymmetric Key Packages (RFC 5958)
90
-
91
-
When an Enterprise Transport Security static Diffie-Hellman public/private key pair are sent from the key manager to a key consumer, they shall be packaged using the Asymmetric Key Package defined in IETF RFC 5958 [3]. Each Asymmetric Key Package shall contain one or more OneAsymmetricKey elements. Such an element will be one of either:
92
-
93
-
a) a static Diffie-Hellman key pair, hereafter referred to as Type A elements; or
94
-
b) a private signing key and a certificate, hereafter referred to as Type B elements.
95
-
96
-
First the case is defined where elements are static Diffie-Hellman key pairs, and so the Asymmetric Key Package shall contain fields and attributes pertaining to these key pairs, defined below. Though certificates are not sent in the same OneAsymmetricKey element as a static key pair, each Asymmetric Key Package may contain one or more Type B elements (server certificates and corresponding private signing keys). Where such Type B elements are sent, all certificates in the Asymmetric Key Package shall be bound to all of the static Diffie-Hellman key pairs in the Asymmetric Key Package. The use of multiple certificates is intended for the situation where it is necessary to provide certificates with different signature algorithms.
97
-
With reference to clause 2 of IETF RFC 5958 [3], the Type A OneAsymmetricKey element used to store each key pair
98
-
in the Asymmetric Key Package shall have the following fields set as follows:
99
-
100
-
1) Version shall be set to version 2 (integer value of 1).
101
-
2) privateKeyAlgorithm shall be set to the key pair algorithm identifier (see below).
102
-
3) privateKey shall be set to the Diffie-Hellman private key encoded as an octet string.
103
-
4) publicKey shall be set to the Diffie-Hellman public key encoded as a bit string.
104
-
5) Attributes shall include a validity period for the key pair using the attribute defined in clause 15 of IETF RFC 7906 [4].
38
+
1) Generating ETSI HTTP request
39
+
2) Parsing HTTP response
40
+
3) Unbundling asymmetric key
105
41
106
42
107
43
## Installation
@@ -148,14 +84,56 @@ $ sudo make install
148
84
149
85
Note: A custom install location can be specified using: `./configure --prefix=/opt/local`
a) `fingerprints` shall be present and its value, `[fingerprints]`, shall be either empty or shall be a comma-separated list of the hexadecimal string representation where each entry in the list is the static Diffie-Hellman public key fingerprint, as defined in clause 4.3.3, for which the corresponding public/private key pairs are being requested.
102
+
103
+
b) The key manager shall return a key package that contains the corresponding public/private key pair for each fingerprint for which it has a record. In the unlikely case that the key manager has more than one public/private key pair corresponding to a given fingerprint, it shall return all of them in the key package. If `[fingerprints]` is empty, the actions of the implementation are out of scope of the present document.
104
+
105
+
c) The key manager shall return an appropriate HTTP error code if there is not at least one matching public/private key pair [12].
106
+
107
+
Example:
108
+
109
+
```
110
+
GET /.well-known/enterprise-transport-security/keys?fingerprints=00010203040506070809,09080706050403020100
111
+
Accept: application/pkcs8, application/cms
112
+
```
113
+
114
+
### ETSI Push (HTTPS PUT)
115
+
116
+
The key consumer shall support receiving a key package via an HTTP PUT request to a request-target, given here in origin-form, of `/enterprise-transport-security/keys`.
117
+
118
+
119
+
### Asymmetric Key Packages (RFC 5958)
120
+
121
+
When an Enterprise Transport Security static Diffie-Hellman public/private key pair are sent from the key manager to a key consumer, they shall be packaged using the Asymmetric Key Package defined in IETF RFC 5958 [3]. Each Asymmetric Key Package shall contain one or more OneAsymmetricKey elements. Such an element will be one of either:
122
+
123
+
a) a static Diffie-Hellman key pair, hereafter referred to as Type A elements; or
124
+
b) a private signing key and a certificate, hereafter referred to as Type B elements.
125
+
126
+
First the case is defined where elements are static Diffie-Hellman key pairs, and so the Asymmetric Key Package shall contain fields and attributes pertaining to these key pairs, defined below. Though certificates are not sent in the same OneAsymmetricKey element as a static key pair, each Asymmetric Key Package may contain one or more Type B elements (server certificates and corresponding private signing keys). Where such Type B elements are sent, all certificates in the Asymmetric Key Package shall be bound to all of the static Diffie-Hellman key pairs in the Asymmetric Key Package. The use of multiple certificates is intended for the situation where it is necessary to provide certificates with different signature algorithms.
127
+
With reference to clause 2 of IETF RFC 5958 [3], the Type A OneAsymmetricKey element used to store each key pair
128
+
in the Asymmetric Key Package shall have the following fields set as follows:
129
+
130
+
1) Version shall be set to version 2 (integer value of 1).
131
+
2) privateKeyAlgorithm shall be set to the key pair algorithm identifier (see below).
132
+
3) privateKey shall be set to the Diffie-Hellman private key encoded as an octet string.
133
+
4) publicKey shall be set to the Diffie-Hellman public key encoded as a bit string.
134
+
5) Attributes shall include a validity period for the key pair using the attribute defined in clause 15 of IETF RFC 7906 [4].
135
+
136
+
### Server Certificate Visibility
159
137
160
138
The ETSI specification part 3 section 4.3.3 requires the TLS server to present a "visibility" information field indicating "Enterrpise Transport Security" is being used.
161
139
@@ -169,6 +147,11 @@ where the SHA-256 digest of the static Diffie-Hellman public key as transmitted
169
147
170
148
See Recommendation ITU-T X.509 (10/2016) | ISO/IEC 9594-8: "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks".
171
149
150
+
## Outstanding Features
151
+
152
+
1) Add TLS mutual authentication to ETSI example.
153
+
2) Add example for HTTP server "VisibilityInformation" extension.
154
+
172
155
## Support
173
156
174
157
For questions or to request an evaluation package please email [email protected]
0 commit comments