From b6eae733922dfa4f2c972e3e50e99286c0f5c34c Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 11 Aug 2021 11:12:15 +0200 Subject: [PATCH 01/36] Add issuer, subject and extension requirements to proposal.md profiles --- proposal.md | 205 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 196 insertions(+), 9 deletions(-) diff --git a/proposal.md b/proposal.md index 8cac35d..8d8b6c7 100644 --- a/proposal.md +++ b/proposal.md @@ -15,25 +15,212 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, ## 2. Arrowhead X.509 Profiles -### 2.1 Root +### 2.1 Master + +#### Issuer + +Any suitable RFC 5280 certificate, or none at all. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `master` | +| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: true, pathLenConstraint: 2 | +| KeyUsage | Yes | keyCertSign, cRLSign | ### 2.2 Organization -### 2.3 Gateway +#### Issuer + +A _Master_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `organization` | +| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: true, pathLenConstraint: 1 | +| KeyUsage | Yes | keyCertSign, cRLSign | + +### 2.3 Gatekeeper + +#### Issuer + +A _Master_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | +| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of gatekeeper system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | + +### 2.4 Gateway + +#### Issuer + +A _Master_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | +| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of gateway system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | + +### 2.5 Local Cloud + +#### Issuer + +An _Organization_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `localcloud` | +| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: true, pathLenConstraint: 0 | +| KeyUsage | Yes | keyCertSign, cRLSign | + +### 2.6 On-Boarding + +#### Issuer + +A _Local Cloud_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `onboarding` | +| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of on-boarded device matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | + +### 2.7 Device + +#### Issuer + +A _Local Cloud_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `device` | +| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of device matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | + +### 2.8 System + +#### Issuer + +A _Local Cloud_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | +| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | + +#### Extensions + +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | + +### 2.9 Operator + +#### Issuer + +A _Local Cloud_ certificate. + +#### Subject + +| RDN | OID | Required | Value | +|:----|:----|:---------|:------| +| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `operator` | +| Common Name (CN) | 2.5.4.3 | Yes | Name of operator. | + +#### Extensions -### 2.4 Local Cloud +| Extension | Critical | Value | +|:----------|:---------|:------| +| BasicConstraints | Yes | cA: false | +| KeyUsage | Yes | digitalSignature, keyEncipherment | +| ExtendedKeyUsage | Yes | serverAuth, clientAuth | -### 2.5 On-Boarding +### 2.10 Manufacturer -### 2.6 Device +#### Issuer -### 2.7 System +Any or none at all. -### 2.8 Operator +### 2.11 Transfer -### 2.9 Manufacturer +#### Issuer -### 2.10 Transfer +A _Manufacturer_ certificate. ## 3. Algorithms, Key Lengths and Other Security Details From e0cea81d893fce9d0a6c9f4c1def05943caf2e82 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 11 Aug 2021 13:53:15 +0200 Subject: [PATCH 02/36] Work on naming and extension requirements for proposal.md profiles --- proposal.md | 207 +++++++++++++++++++++++++--------------------------- 1 file changed, 99 insertions(+), 108 deletions(-) diff --git a/proposal.md b/proposal.md index 8d8b6c7..eb93a4f 100644 --- a/proposal.md +++ b/proposal.md @@ -15,6 +15,15 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, ## 2. Arrowhead X.509 Profiles +__Entity naming__. +Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including the names in domain names. +The reason for this is to guarantee compatibility with DNS-SD, and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). +In other words, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. +This means that full domain names are _not_ allowed as subject CN, such as `my-device.company.arrowhead.eu`. +In the case of that example, it should rather have been `my-device`. +Full domain names must instead be specified as subject alternative names where relevant. + ### 2.1 Master #### Issuer @@ -23,41 +32,20 @@ Any suitable RFC 5280 certificate, or none at all. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `master` | -| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | - -#### Extensions - -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: true, pathLenConstraint: 2 | -| KeyUsage | Yes | keyCertSign, cRLSign | - -### 2.2 Organization - -#### Issuer - -A _Master_ certificate. - -#### Subject - -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `organization` | -| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `master` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: true, pathLenConstraint: 1 | -| KeyUsage | Yes | keyCertSign, cRLSign | +| Extension | Critical | Value | +|:-----------------|:---------|:------| +| BasicConstraints | Yes | `cA: true, pathLenConstraint: 2` | +| KeyUsage | Yes | `keyCertSign, cRLSign` | -### 2.3 Gatekeeper +### 2.2 Gate #### Issuer @@ -65,21 +53,22 @@ A _Master_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | -| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of gatekeeper system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `gate` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:------------------------|:---------|:------| +| BasicConstraints | Yes | `cA: false` | +| KeyUsage | Yes | `digitalSignature, keyEncipherment` | +| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | +| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.4 Gateway +### 2.3 Organization #### Issuer @@ -87,21 +76,20 @@ A _Master_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | -| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of gateway system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `organization` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:-----------------|:---------|:------| +| BasicConstraints | Yes | `cA: true, pathLenConstraint: 1` | +| KeyUsage | Yes | `keyCertSign, cRLSign` | -### 2.5 Local Cloud +### 2.4 Local Cloud #### Issuer @@ -109,20 +97,20 @@ An _Organization_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `localcloud` | -| Common Name (CN) | 2.5.4.3 | Yes | Human-readable name of certificate. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `localcloud` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: true, pathLenConstraint: 0 | -| KeyUsage | Yes | keyCertSign, cRLSign | +| Extension | Critical | Value | +|:-----------------|:---------|:------| +| BasicConstraints | Yes | `cA: true, pathLenConstraint: 0` | +| KeyUsage | Yes | `keyCertSign, cRLSign` | -### 2.6 On-Boarding +### 2.5 On-Boarding #### Issuer @@ -130,21 +118,22 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `onboarding` | -| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of on-boarded device matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `onboarding` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:------------------------|:---------|:------| +| BasicConstraints | Yes | `cA: false` | +| KeyUsage | Yes | `digitalSignature, keyEncipherment` | +| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | +| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.7 Device +### 2.6 Device #### Issuer @@ -152,21 +141,22 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `device` | -| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of device matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `device` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:------------------------|:---------|:------| +| BasicConstraints | Yes | `cA: false` | +| KeyUsage | Yes | `digitalSignature, keyEncipherment` | +| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | +| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.8 System +### 2.7 System #### Issuer @@ -174,21 +164,22 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `system` | -| Common Name (CN) | 2.5.4.3 | Yes | Machine-readable name of system matching `[a-z](-[0-9a-z]+)*[0-9a-z]?`. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `system` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:------------------------|:---------|:------| +| BasicConstraints | Yes | `cA: false` | +| KeyUsage | Yes | `digitalSignature, keyEncipherment` | +| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | +| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.9 Operator +### 2.8 Operator #### Issuer @@ -196,27 +187,27 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:----|:----|:---------|:------| -| Organization (O) | 2.5.4.6 | Yes | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | 2.5.4.46 | Yes | `operator` | -| Common Name (CN) | 2.5.4.3 | Yes | Name of operator. | +| RDN | OID | Required | Value | +|:-------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `operator` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | #### Extensions -| Extension | Critical | Value | -|:----------|:---------|:------| -| BasicConstraints | Yes | cA: false | -| KeyUsage | Yes | digitalSignature, keyEncipherment | -| ExtendedKeyUsage | Yes | serverAuth, clientAuth | +| Extension | Critical | Value | +|:------------------------|:---------|:------| +| BasicConstraints | Yes | `cA: false` | +| KeyUsage | Yes | `digitalSignature, keyEncipherment` | +| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | -### 2.10 Manufacturer +### 2.9 Manufacturer #### Issuer Any or none at all. -### 2.11 Transfer +### 2.10 Transfer #### Issuer From 8ad35ff4a54bc91511a2f79ca27a29112bb86b6c Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 11 Aug 2021 14:04:53 +0200 Subject: [PATCH 03/36] Work on proposal.md --- proposal.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/proposal.md b/proposal.md index eb93a4f..8e2dba0 100644 --- a/proposal.md +++ b/proposal.md @@ -17,12 +17,12 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, __Entity naming__. Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. -While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including the names in domain names. -The reason for this is to guarantee compatibility with DNS-SD, and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). -In other words, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. +While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. +The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). +Concretely, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. This means that full domain names are _not_ allowed as subject CN, such as `my-device.company.arrowhead.eu`. In the case of that example, it should rather have been `my-device`. -Full domain names must instead be specified as subject alternative names where relevant. +Full domain names are specified as subject alternative names where relevant. ### 2.1 Master @@ -99,7 +99,6 @@ An _Organization_ certificate. | RDN | OID | Required | Value | |:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DNQ) | `2.5.4.46` | Yes | `localcloud` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -120,7 +119,6 @@ A _Local Cloud_ certificate. | RDN | OID | Required | Value | |:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DNQ) | `2.5.4.46` | Yes | `onboarding` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -143,7 +141,6 @@ A _Local Cloud_ certificate. | RDN | OID | Required | Value | |:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DNQ) | `2.5.4.46` | Yes | `device` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -189,7 +186,6 @@ A _Local Cloud_ certificate. | RDN | OID | Required | Value | |:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DNQ) | `2.5.4.46` | Yes | `operator` | | Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | From c11b9ff135c6b2a38fde920b8b52806a04b7652a Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 11 Aug 2021 16:07:14 +0200 Subject: [PATCH 04/36] Add OIDs to Extensions listed in proposal.md --- proposal.md | 82 ++++++++++++++++++++++++++--------------------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/proposal.md b/proposal.md index 8e2dba0..1d2814e 100644 --- a/proposal.md +++ b/proposal.md @@ -40,10 +40,10 @@ Any suitable RFC 5280 certificate, or none at all. #### Extensions -| Extension | Critical | Value | -|:-----------------|:---------|:------| -| BasicConstraints | Yes | `cA: true, pathLenConstraint: 2` | -| KeyUsage | Yes | `keyCertSign, cRLSign` | +| Extension | OID | Critical | Value | +|:-----------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2` | +| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | ### 2.2 Gate @@ -61,12 +61,12 @@ A _Master_ certificate. #### Extensions -| Extension | Critical | Value | -|:------------------------|:---------|:------| -| BasicConstraints | Yes | `cA: false` | -| KeyUsage | Yes | `digitalSignature, keyEncipherment` | -| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | -| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.3 Organization @@ -84,10 +84,10 @@ A _Master_ certificate. #### Extensions -| Extension | Critical | Value | -|:-----------------|:---------|:------| -| BasicConstraints | Yes | `cA: true, pathLenConstraint: 1` | -| KeyUsage | Yes | `keyCertSign, cRLSign` | +| Extension | OID | Critical | Value | +|:-----------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1` | +| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | ### 2.4 Local Cloud @@ -104,10 +104,10 @@ An _Organization_ certificate. #### Extensions -| Extension | Critical | Value | -|:-----------------|:---------|:------| -| BasicConstraints | Yes | `cA: true, pathLenConstraint: 0` | -| KeyUsage | Yes | `keyCertSign, cRLSign` | +| Extension | OID | Critical | Value | +|:-----------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0` | +| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | ### 2.5 On-Boarding @@ -124,12 +124,12 @@ A _Local Cloud_ certificate. #### Extensions -| Extension | Critical | Value | -|:------------------------|:---------|:------| -| BasicConstraints | Yes | `cA: false` | -| KeyUsage | Yes | `digitalSignature, keyEncipherment` | -| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | -| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.6 Device @@ -146,12 +146,12 @@ A _Local Cloud_ certificate. #### Extensions -| Extension | Critical | Value | -|:------------------------|:---------|:------| -| BasicConstraints | Yes | `cA: false` | -| KeyUsage | Yes | `digitalSignature, keyEncipherment` | -| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | -| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.7 System @@ -169,12 +169,12 @@ A _Local Cloud_ certificate. #### Extensions -| Extension | Critical | Value | -|:------------------------|:---------|:------| -| BasicConstraints | Yes | `cA: false` | -| KeyUsage | Yes | `digitalSignature, keyEncipherment` | -| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | -| SubjectAlternativeNames | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.8 Operator @@ -191,11 +191,11 @@ A _Local Cloud_ certificate. #### Extensions -| Extension | Critical | Value | -|:------------------------|:---------|:------| -| BasicConstraints | Yes | `cA: false` | -| KeyUsage | Yes | `digitalSignature, keyEncipherment` | -| ExtendedKeyUsage | Yes | `serverAuth, clientAuth` | +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | ### 2.9 Manufacturer From 27fb34a13ba5f0cce23d0da37327fed37a7c99ad Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 11 Aug 2021 16:19:26 +0200 Subject: [PATCH 05/36] Add known limitations section to proposal.md --- proposal.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/proposal.md b/proposal.md index 1d2814e..37a1ad1 100644 --- a/proposal.md +++ b/proposal.md @@ -215,4 +215,13 @@ A _Manufacturer_ certificate. ## 5. DNS Support and Security Implications +## 6. Known Limitations + +### Subject Alternative Names and Device Mobility + +Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. +This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. +However, as mobility at a scale that makes this setup a problem are currently deemed of marginal utility, no provisions are given for it directly. +It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. + ## References From c553fca7f7895d5e62eab80af177921e0054ad9b Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 12 Aug 2021 10:32:02 +0200 Subject: [PATCH 06/36] Work on proposal.md --- proposal.md | 88 +++++++++++++++++++++++++---------------------------- 1 file changed, 42 insertions(+), 46 deletions(-) diff --git a/proposal.md b/proposal.md index 37a1ad1..9d751ad 100644 --- a/proposal.md +++ b/proposal.md @@ -32,11 +32,11 @@ Any suitable RFC 5280 certificate, or none at all. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `master` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | `master` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | #### Extensions @@ -53,19 +53,18 @@ A _Master_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `gate` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | `gate` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions | Extension | OID | Critical | Value | |:------------------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | | KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.3 Organization @@ -76,11 +75,11 @@ A _Master_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `organization` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | `organization` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | #### Extensions @@ -97,10 +96,10 @@ An _Organization_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `localcloud` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| DN Qualifier (DN) | `2.5.4.46` | Yes | `localcloud` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions @@ -117,18 +116,17 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `onboarding` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| DN Qualifier (DN) | `2.5.4.46` | Yes | `onboarding` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions | Extension | OID | Critical | Value | |:------------------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | | KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.6 Device @@ -139,18 +137,17 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `device` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| DN Qualifier (DN) | `2.5.4.46` | Yes | `device` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions | Extension | OID | Critical | Value | |:------------------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | | KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.7 System @@ -161,19 +158,18 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `system` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | `system` | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | #### Extensions | Extension | OID | Critical | Value | |:------------------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | | KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | ### 2.8 Operator @@ -184,18 +180,18 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | -|:-------------------|:-----------|:---------|:------| -| DN Qualifier (DNQ) | `2.5.4.46` | Yes | `operator` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| DN Qualifier (DN) | `2.5.4.46` | Yes | `operator` | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | #### Extensions | Extension | OID | Critical | Value | |:------------------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: false` | | KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | Yes | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the devices from which the operator administers its local cloud. | ### 2.9 Manufacturer From 1e60330bce9b793596ab691877c298da10eca1bd Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 12 Aug 2021 15:04:08 +0200 Subject: [PATCH 07/36] Work on proposal.md --- proposal.md | 127 +++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 101 insertions(+), 26 deletions(-) diff --git a/proposal.md b/proposal.md index 9d751ad..d476b5e 100644 --- a/proposal.md +++ b/proposal.md @@ -11,9 +11,73 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, ### 1.2 Relation to the IETF RFC 5280 X.509 Profile -### 1.3 Conventions +### 1.3 Significant Terminology -## 2. Arrowhead X.509 Profiles +| Term | Definition | +|:-----|:-----------| +| Arrowhead | | +| CA | Certificate Authority, which may issue (sign) other certificates to endorse their validity. | +| Intermediary | | +| End Entity | | +| Local Cloud | | + +### 1.4 Conventions + +## 2. Arrowhead X.509 Profile Categories + +```asn1 +TBSCertificate ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, -- Must be v3(2) + serialNumber CertificateSerialNumber, -- Should (must?) be cryto rand number + signature AlgorithmIdentifier, -- Must be trusted crypto + issuer Name, -- Taken from issuer cert + validity Validity, + subject Name, + subjectPublicKeyInfo SubjectPublicKeyInfo, -- Must be trusted crypto + issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- Must NOT be used + subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- Must NOT be used + extensions [3] EXPLICIT Extensions OPTIONAL +} +``` + +Prefer `PrintableString` in `Name`s; `UTF8String` also OK. + +### 2.1 CA Certificates + +#### 2.1.1 Validity + +TODO: Write something about sensible validity periods for certs. + +#### 2.1.2 Subject + +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | + +#### 2.1.3 Extensions + +| Extension | OID | Critical | Value | +|:-----------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: n*` | +| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | + +* each profile specifies its own `n`. + +### 2.2 End Entity Certificates + +#### 2.2.1 Validity + +TODO: Write something about sensible validity periods for certs. + +#### 2.2.2 Subject + +| RDN | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | __Entity naming__. Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. @@ -24,32 +88,43 @@ This means that full domain names are _not_ allowed as subject CN, such as `my-d In the case of that example, it should rather have been `my-device`. Full domain names are specified as subject alternative names where relevant. -### 2.1 Master +#### 2.2.3 Extensions -#### Issuer +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -Any suitable RFC 5280 certificate, or none at all. +### 2.3 Transfer Certificates -#### Subject +## 3. Arrowhead X.509 Profiles + +### 3.1 Master + +#### 3.1.1 Issuer + +Issued by any suitable RFC 5280 certificate, or none at all (self-signed). + +#### 3.1.2 Validity + +#### 3.1.3 Subject | RDN | OID | Required | Value | |:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DN) | `2.5.4.46` | Yes | `master` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | -#### Extensions +#### 2.1.3 Extensions | Extension | OID | Critical | Value | |:-----------------|:------------|:---------|:------| | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2` | -| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | -### 2.2 Gate +### 3.2 Gate -#### Issuer -A _Master_ certificate. + +Issued by a _Master_ certificate. #### Subject @@ -67,7 +142,7 @@ A _Master_ certificate. | ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.3 Organization +### 3.3 Organization #### Issuer @@ -88,7 +163,7 @@ A _Master_ certificate. | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1` | | KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | -### 2.4 Local Cloud +### 3.4 Local Cloud #### Issuer @@ -108,7 +183,7 @@ An _Organization_ certificate. | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0` | | KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | -### 2.5 On-Boarding +### 3.5 On-Boarding #### Issuer @@ -129,7 +204,7 @@ A _Local Cloud_ certificate. | ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.6 Device +### 3.6 Device #### Issuer @@ -150,7 +225,7 @@ A _Local Cloud_ certificate. | ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.7 System +### 3.7 System #### Issuer @@ -172,7 +247,7 @@ A _Local Cloud_ certificate. | ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | -### 2.8 Operator +### 3.8 Operator #### Issuer @@ -193,27 +268,27 @@ A _Local Cloud_ certificate. | ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | | SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the devices from which the operator administers its local cloud. | -### 2.9 Manufacturer +### 3.9 Manufacturer #### Issuer Any or none at all. -### 2.10 Transfer +### 3.10 Transfer #### Issuer A _Manufacturer_ certificate. -## 3. Algorithms, Key Lengths and Other Security Details +## 4. Algorithms, Key Lengths and Other Security Details -## 4. Certificate Creation and Distribution +## 5. Certificate Creation and Distribution -## 5. DNS Support and Security Implications +## 6. DNS Support and Security Implications -## 6. Known Limitations +## 7. Known Limitations -### Subject Alternative Names and Device Mobility +### 7.1 Subject Alternative Names and Device Mobility Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. From 73e285aaa788d19938464b354a51438a3b842c21 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 13 Aug 2021 10:52:35 +0200 Subject: [PATCH 08/36] Work on proposal.md --- proposal.md | 206 ++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 184 insertions(+), 22 deletions(-) diff --git a/proposal.md b/proposal.md index d476b5e..efe443a 100644 --- a/proposal.md +++ b/proposal.md @@ -9,38 +9,200 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, ### 1.1 The X.509 Standard -### 1.2 Relation to the IETF RFC 5280 X.509 Profile +### 1.2 Significant Terminology -### 1.3 Significant Terminology +#### 1.2.1 Terms Related to Eclipse Arrowhead -| Term | Definition | -|:-----|:-----------| -| Arrowhead | | -| CA | Certificate Authority, which may issue (sign) other certificates to endorse their validity. | -| Intermediary | | -| End Entity | | -| Local Cloud | | +| Term | Definition | +|:-------------|:-----------| +| Arrowhead | Service-oriented architecture for Industry 4.0 automation. | +| Device | A physical machine that could be capable of hosting Arrowhead _systems_. | +| Local Cloud | A physical or logical protected network consisting of communicating _systems_. | +| Service | An explicitly defined network application interface accessible to authorized _systems_. | +| System | A software application providing Arrowhead-compliant _services_ that runs on a _device_. | + +#### 1.2.2 Terms Related to X.509 + +| Term | Abbreviation | Definition | +|:-----------------------------|:-------------|:-----------| +| Certificate Authority | CA | Entity issuing (signing) other certificates to endorse their validity. | +| Distinguished Encoding Rules | DER | An encoding format defined for ASN.1. | +| Distinguished Name | DN | A hierarchical naming format defined by X.500. A DN contains RDNs. | +| End Entity | | Entity having but not issuing certificates. | +| Entity | | Any thing or being potentially able to hold and use an X.509 certificate. | +| Intermediary CA | | CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. | +| Relative Distinguished Name | RDN | A list of attribute/value pairs belonging to the same hierarchical level in a DN. | +| Root CA | | CA that _did_ issue (self-sign) its own certificate and, therefore, must be explicitly trusted. | + +### 1.3 Relation to the IETF RFC 5280 X.509 Profile ### 1.4 Conventions -## 2. Arrowhead X.509 Profile Categories +## 2. Certificate Profiles + +## 2.1 Basic Certificate Fields + +The X.509 version 3 certificate has the below ASN.1 syntax, as defined in RFC 5280. +Note that RFC 5280 demands that the certificate be encoded using DER. ```asn1 -TBSCertificate ::= SEQUENCE { - version [0] EXPLICIT Version DEFAULT v1, -- Must be v3(2) - serialNumber CertificateSerialNumber, -- Should (must?) be cryto rand number - signature AlgorithmIdentifier, -- Must be trusted crypto - issuer Name, -- Taken from issuer cert - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo, -- Must be trusted crypto - issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- Must NOT be used - subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- Must NOT be used - extensions [3] EXPLICIT Extensions OPTIONAL + Certificate ::= SEQUENCE { + tbsCertificate TBSCertificate, + signatureAlgorithm AlgorithmIdentifier, + signatureValue BIT STRING + } + + TBSCertificate ::= SEQUENCE { + version [0] EXPLICIT Version DEFAULT v1, + serialNumber INTEGER, + signature AlgorithmIdentifier, + issuer Name, + validity Validity, + subject Name, + subjectPublicKeyInfo SubjectPublicKeyInfo, + issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, + subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, + extensions [3] EXPLICIT Extensions OPTIONAL + } +``` + +In this section, we will go through each of these fields and clarify what they signify and how they must or may be set in conforming Arrowhead X.509 certificates. +The section is by no means an attempt to rigorously define these fields. +Please consult RFC 5280 and X.509 for more exact details. + +### 2.1.1 `Certificate` + +A certificate and its signature. + +#### 2.1.1.1 `tbsCertificate` + +The part of the certificate whose integrity is guaranteed by the `signatureAlgorithm` and `signatureValue` fields. + +#### 2.1.1.2 `signatureAlgorithm` + +The cryptographic signature algorithm used to produce `signatureValue` and any parameters made relevant by the algorithm type. +Examples of algorithms could be _RSA with SHA256_ or _ED25519_. + +This field must contain the same algorithm as the `signature` field in the `tbsCertificate`, as described in Section 2.1.2.3. + +#### 2.1.1.3 `signatureValue` + +A string of arbitrary bytes whose length is determined by the output of the `signatureAlgorithm`. +The value is used together with `signatureAlgorithm` and the public key of the issuer of the certificate to validate its integrity. + +### 2.1.2 `TBSCertificate` + +A certificate covered by, but not including, a signature. + +#### 2.1.2.1 `version` + +X.509 version of the certificate. +Must always be `v3(2)`. + +RFC 5280 recommends that `v1(0)` and `v2(1)` certificates be used when the additional fields of later versions are unused. +It does only require that `v3(2)` be supported, however. +As we rely on certificate extensions for all of our profiles, we always require `v3(2)`. + +#### 2.1.2.2 `serialNumber` + +A positive integer of no more than 20 octets uniquely assigned by the issuer of the certificate. + +__Recommendation__. +The serial number should be exactly 20 octets long and be produced by a cryptographic random number generator. +This serves both to (A) make the certificate more resistant to collision attacks and (B) to prevent the serial number from leaking important details about the certificate issuer, such as how many certificates it has issued, how long the signing process took, and so on. +Note that the number is signed and must be positive, which means that the most significant bit of the first DER `INTEGER` octet must be 0. + +#### 2.1.2.3 `signature` + +The cryptographic signature algorithm used to produce `signatureValue` of `Certificate` and any parameters made relevant by the algorithm type. +Examples of algorithms could be _RSA with SHA256_ or _ED25519_. + +This field must contain the same algorithm as the `signatureAlorithm` field in the `Certificate`, as described in Section 2.1.1.2. + +#### 2.1.2.4 `issuer` + +The DN of the issuer of the certificate in question. +More specifically, this field contains a copy of the `subject` field of Section 2.1.2.6 from the issuer's certificate. + +#### 2.1.2.5 `validity` + +The period during which the certificate _may_ remain active and its issuer is bound to know whether or not the certificate has been revoked or not. +Denoted as a duration between two timestamps, `notBefore` and `notAfter`, as show below. + +```asn1 +Validity ::= SEQUENCE { + notBefore Time, + notAfter Time +} + +Time ::= CHOICE { + utcTime UTCTime, + generalTime GeneralizedTime } ``` -Prefer `PrintableString` in `Name`s; `UTF8String` also OK. +For each of these two dates, the date in question _must_ be encoded as a `UTCTime` if its year is less than or equal to 2049, or as a `GeneralizedTime` if the year is equal to or greater than 2050. +More details about the validity format may be read in Section 4.1.2.5 of RFC 5280. + +#### 2.1.2.6 `subject` + +```asn1 +Name ::= CHOICE { + rdnSequence RDNSequence +} + +RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + +RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue + +AttributeTypeAndValue ::= SEQUENCE { + type AttributeType, + value AttributeValue +} + +AttributeType ::= OBJECT IDENTIFIER + +-- Concrete type determined by associated `AttributeType`. +-- In our case that type will always be `DirectoryString`. +AttributeValue ::= ANY + +DirectoryString ::= CHOICE { + teletexString TeletexString (SIZE (1..MAX)), + printableString PrintableString (SIZE (1..MAX)), -- ASCII subset. Preferred. + universalString UniversalString (SIZE (1..MAX)), + utf8String UTF8String (SIZE (1..MAX)), -- Use when `PrintableString` is insufficient. + bmpString BMPString (SIZE (1..MAX)) +} +``` + +#### 2.1.2.7 `subjectPublicKeyInfo` + +```asn1 +SubjectPublicKeyInfo ::= SEQUENCE { + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING +} +``` + +#### 2.1.2.8 `issuerUniqueID` + +An optional identifier uniquely associated with the issuer of the certificate. This field must not be used. + +#### 2.1.2.9 `subjectUniqueID` + +An optional identifier uniquely associated with the subject of the certificate. This field must not be used. + +#### 2.1.2.10 `extensions` + +```asn1 +Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension + +Extension ::= SEQUENCE { + extnID OBJECT IDENTIFIER, + critical BOOLEAN DEFAULT FALSE, + extnValue OCTET STRING +} +``` ### 2.1 CA Certificates From 28dd8c1f64fffaa9e336256e5866ed9bcdfdc0e6 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 16 Aug 2021 11:08:59 +0200 Subject: [PATCH 09/36] Work on proposal.md --- proposal.md | 81 ++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 56 insertions(+), 25 deletions(-) diff --git a/proposal.md b/proposal.md index efe443a..24c2eaa 100644 --- a/proposal.md +++ b/proposal.md @@ -7,39 +7,68 @@ It describes the certificates of Certificate Authorities (CAs) and end entities, ## 1. Introduction -### 1.1 The X.509 Standard +TODO + +### 1.1 Relation to the IETF RFC 5280 X.509 Profile + +All certificate profiles in this document, with the exception of the _Manufacturer_ and _Transfer_ profiles of Sections 3.9 and 3.10, are meant to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. +Most significantly, this makes our profiles compatible with many implementations the TLS and DTLS standards for secure communication, even though complying to this document will require additional validation steps, such as ensuring that certain extensions are being or not being used. +Those steps are outlined in Section 6. + +Building on top of RFC 5280 and X.509 means that also X.501 and ASN.1 become relevant to this document, as those standards define the subject/issuer naming schema and syntax notation used by X.509. +In particular, the interface description language of ASN.1 is used here to describe relevant certificate constituents. +Please refer to ASN.1 or a relevant learning resource if wanting to know more about its syntax. ### 1.2 Significant Terminology -#### 1.2.1 Terms Related to Eclipse Arrowhead +The following subsections represent technical domains with particular bearing on this document. +Each subsection briefly describes the domain and lists terms relevant to our purposes. + +#### 1.2.1 Eclipse Arrowhead + +Service-oriented architecture for Industry 4.0 automation. + +- __Device__: A physical machine that could be capable of hosting Arrowhead _systems_. +- __Local Cloud__: A physical or logical protected network consisting of communicating _systems_. +- __Service__: An explicitly defined network application interface accessible to authorized _systems_. +- __System__: A software application providing Arrowhead-compliant _services_ that runs on a _device_. + +#### 1.2.2 X.509 -| Term | Definition | -|:-------------|:-----------| -| Arrowhead | Service-oriented architecture for Industry 4.0 automation. | -| Device | A physical machine that could be capable of hosting Arrowhead _systems_. | -| Local Cloud | A physical or logical protected network consisting of communicating _systems_. | -| Service | An explicitly defined network application interface accessible to authorized _systems_. | -| System | A software application providing Arrowhead-compliant _services_ that runs on a _device_. | +Certificate standard for establishing trust between devices over untrusted computer networks. -#### 1.2.2 Terms Related to X.509 +- __Certificate Authority (CA)__: Entity issuing (signing) other certificates to endorse their validity. +- __End Entity__: Entity having but not issuing certificates. +- __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. +- __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. +- __Root CA__: CA that _did_ issue (self-sign) its own certificate and, therefore, must be explicitly trusted. +- __Trust Anchor__: Another name for CA. -| Term | Abbreviation | Definition | -|:-----------------------------|:-------------|:-----------| -| Certificate Authority | CA | Entity issuing (signing) other certificates to endorse their validity. | -| Distinguished Encoding Rules | DER | An encoding format defined for ASN.1. | -| Distinguished Name | DN | A hierarchical naming format defined by X.500. A DN contains RDNs. | -| End Entity | | Entity having but not issuing certificates. | -| Entity | | Any thing or being potentially able to hold and use an X.509 certificate. | -| Intermediary CA | | CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. | -| Relative Distinguished Name | RDN | A list of attribute/value pairs belonging to the same hierarchical level in a DN. | -| Root CA | | CA that _did_ issue (self-sign) its own certificate and, therefore, must be explicitly trusted. | +#### 1.2.3 X.501 -### 1.3 Relation to the IETF RFC 5280 X.509 Profile +Naming schema for X.500 directories. +The standard is relevant as it is used to name X.509 certificates. -### 1.4 Conventions +- __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. `,` is used to delimit the pairs. +- __Relative Distinguished Name (RDN)__: A list of attribute/value pairs belonging to the same hierarchical level in a DN. Examples of RDNs could be `O=My Company` and `CN=Robert Robertson+E=robert@mail.com`. The first RDN consists of a single pair while the second consists of two delimited by `+`. + +#### 1.2.4 ASN.1 + +Interface description language for describing messages that can be sent or received over a computer network. +The standard is relevant as it is used to describe the structure of X.509 certificates. + +- __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 schema. +- __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation. Must be used when encoding X.509 certificates. + +### 1.3 Conventions + +The words _must_, _must not_, _required_, _shall_, _shall not_, _should_, _should not_, _recommended_, _may_, and _optional_ in this document are to be interpreted as described in IETF RFC 2119. +In short, this means that _must_, _required_ and _shall_ denote absolute requirements; _must not_ and _shall not_ denote absolute prohibitions; _should_, _should not_ and _recommended_ denote recommendations; and, finally, _may_ and _optional_ denote the subject of concern being truly optional. ## 2. Certificate Profiles +TODO + ## 2.1 Basic Certificate Fields The X.509 version 3 certificate has the below ASN.1 syntax, as defined in RFC 5280. @@ -446,11 +475,13 @@ A _Manufacturer_ certificate. ## 5. Certificate Creation and Distribution -## 6. DNS Support and Security Implications +## 6. Authentication and Authorization + +## 7. DNS Support and its Security Implications -## 7. Known Limitations +## 8. Known Limitations -### 7.1 Subject Alternative Names and Device Mobility +### 8.1 Subject Alternative Names and Device Mobility Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. From 2eed9cdbcf1c2df47fc13774b9da98cf37f4531b Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 16 Aug 2021 14:20:11 +0200 Subject: [PATCH 10/36] Work on proposal.md --- proposal.md | 74 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 55 insertions(+), 19 deletions(-) diff --git a/proposal.md b/proposal.md index 24c2eaa..6c43ee4 100644 --- a/proposal.md +++ b/proposal.md @@ -41,29 +41,33 @@ Certificate standard for establishing trust between devices over untrusted compu - __End Entity__: Entity having but not issuing certificates. - __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. - __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. +- __Issuer__: The CA that signed a given certificate. +- __Public Key Infrastructure (PKI)__: The structure of entities, each having a certain role, required to facilitate secure certificate distribution. - __Root CA__: CA that _did_ issue (self-sign) its own certificate and, therefore, must be explicitly trusted. -- __Trust Anchor__: Another name for CA. +- __Subject__: The entity owning and being described by a given certificate. +- __Trust Anchor__: Another name for _Root CA_. #### 1.2.3 X.501 Naming schema for X.500 directories. -The standard is relevant as it is used to name X.509 certificates. +The standard is used to name X.509 certificates. -- __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. `,` is used to delimit the pairs. +- __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. The comma character `,` is used to delimit the RDNs. - __Relative Distinguished Name (RDN)__: A list of attribute/value pairs belonging to the same hierarchical level in a DN. Examples of RDNs could be `O=My Company` and `CN=Robert Robertson+E=robert@mail.com`. The first RDN consists of a single pair while the second consists of two delimited by `+`. #### 1.2.4 ASN.1 -Interface description language for describing messages that can be sent or received over a computer network. -The standard is relevant as it is used to describe the structure of X.509 certificates. +Interface description language for describing messages that can be sent or received over computer networks using several associated encodings. +The standard is used to describe the structure of X.509 certificates, which must be encoded using ASN.1 DER, as defined below. -- __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 schema. -- __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation. Must be used when encoding X.509 certificates. +- __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends basic type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 description. Defined in X.690. +- __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation, which is to say that every pair of structurally equivalent ASN.1 messages can be represented in DER in exactly one way. Must be used when encoding X.509 certificates. Defined in X.690. +- __Object Identifier (OID)__: A structured universally unique identifier, useful for identifying parts of ASN.1 messages. ### 1.3 Conventions -The words _must_, _must not_, _required_, _shall_, _shall not_, _should_, _should not_, _recommended_, _may_, and _optional_ in this document are to be interpreted as described in IETF RFC 2119. -In short, this means that _must_, _required_ and _shall_ denote absolute requirements; _must not_ and _shall not_ denote absolute prohibitions; _should_, _should not_ and _recommended_ denote recommendations; and, finally, _may_ and _optional_ denote the subject of concern being truly optional. +The words __must__, __must not__, __required__, __shall__, __shall not__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as described in IETF RFC 2119. +In short, this means that __must__, __required__ and __shall__ denote absolute requirements; __must not__ and __shall not__ denote absolute prohibitions; __should__, __should not__ and __recommended__ denote recommendations; and, finally, __may__ and __optional__ denote the subject of concern being truly optional. ## 2. Certificate Profiles @@ -143,15 +147,12 @@ Note that the number is signed and must be positive, which means that the most s #### 2.1.2.3 `signature` -The cryptographic signature algorithm used to produce `signatureValue` of `Certificate` and any parameters made relevant by the algorithm type. -Examples of algorithms could be _RSA with SHA256_ or _ED25519_. - This field must contain the same algorithm as the `signatureAlorithm` field in the `Certificate`, as described in Section 2.1.1.2. #### 2.1.2.4 `issuer` The DN of the issuer of the certificate in question. -More specifically, this field contains a copy of the `subject` field of Section 2.1.2.6 from the issuer's certificate. +More specifically, this field contains an exact copy of the `subject` field of Section 2.1.2.6 from the certificate of its issuer. #### 2.1.2.5 `validity` @@ -175,6 +176,9 @@ More details about the validity format may be read in Section 4.1.2.5 of RFC 528 #### 2.1.2.6 `subject` +The DN used to describe the owner of the certificate. +The field is defined as follows: + ```asn1 Name ::= CHOICE { rdnSequence RDNSequence @@ -204,8 +208,38 @@ DirectoryString ::= CHOICE { } ``` +The below `AttributeType`s must be supported, in the sense that their OIDs are known to be associated with values of type `DirectoryString`, as defined above. + +| Attribute Type | Abbreviation | OID | +|:-----------------------------|:-------------|:----| +| Common Name | `CN` | `2.5.4.3` +| Country | `C` | `2.5.4.6` +| Distinguished Name Qualifier | `DN` | `2.5.4.46` +| Domain Component | `DC` | `0.9.2342.19200300.100.1.25` +| Organization | `O` | `2.5.4.10` +| Organizational Unit | `OU` | `2.5.4.11` +| Serial Number | `SN` | `2.5.4.5` +| State or Province Name | `ST` | `2.5.4.8` + +In contrast to RFC 5280, we _require_ always that each `AttributeValue` associated with any type of this list is concretely represented as a `PrintableString` or a `UTF8String`. +The former is preferred when its limited character set is sufficient. +See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. + +__Precedence__. +Being _hierarchical_, a DN describes a path from some arbitrary root to the subject or issuer in question, where the root is the leftmost RDN and the subject or issuer is the rightmost. +The root does not have to be associated with the Root CA of the certificate in question. +While the above listed attributes _should not_ appear more than once in a subject or issuer DN, if they do, the rightmost takes precedence during the authorization procedure described in Section 6. + +__Recommendation__. +Every certificate implementing a Section 3 profile _should_ only contain the attributes associated with that profile. +Each attribute _should_ be contained in its own RDN, and the RDNs _should_ be in the same order as they are presented in Section 3. +If a Section 3 attribute is declared as not required, it _may_ be omitted. + #### 2.1.2.7 `subjectPublicKeyInfo` +The public key of the subject, as well as the identity of the algorithm associated with it. +The field is defined as follows. + ```asn1 SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, @@ -213,15 +247,15 @@ SubjectPublicKeyInfo ::= SEQUENCE { } ``` -#### 2.1.2.8 `issuerUniqueID` - -An optional identifier uniquely associated with the issuer of the certificate. This field must not be used. +#### 2.1.2.8 `issuerUniqueID` and `subjectUniqueID` -#### 2.1.2.9 `subjectUniqueID` +Optional identifiers uniquely associated with the issuer or subject of the certificate. -An optional identifier uniquely associated with the subject of the certificate. This field must not be used. +These fields _must not_ be used. +When a certain certificate, or its subject, needs to be identified, the cryptographic hash, or _fingerprint_, of the certificate _should_ be used. +See Section 4 for more information about what hashing algorithms should be used for this and other purposes. -#### 2.1.2.10 `extensions` +#### 2.1.2.9 `extensions` ```asn1 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension @@ -473,6 +507,8 @@ A _Manufacturer_ certificate. ## 4. Algorithms, Key Lengths and Other Security Details +- Use fingerprints to identify certificate owners, not subject names. + ## 5. Certificate Creation and Distribution ## 6. Authentication and Authorization From 77d1aaf0a1ed15f866ed231f6b77b0c6f37d39ac Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 16 Aug 2021 16:30:03 +0200 Subject: [PATCH 11/36] Work on proposal.md --- proposal.md | 169 +++++++++++++++++++++++++++------------------------- 1 file changed, 88 insertions(+), 81 deletions(-) diff --git a/proposal.md b/proposal.md index 6c43ee4..896645a 100644 --- a/proposal.md +++ b/proposal.md @@ -63,6 +63,7 @@ The standard is used to describe the structure of X.509 certificates, which must - __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends basic type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 description. Defined in X.690. - __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation, which is to say that every pair of structurally equivalent ASN.1 messages can be represented in DER in exactly one way. Must be used when encoding X.509 certificates. Defined in X.690. - __Object Identifier (OID)__: A structured universally unique identifier, useful for identifying parts of ASN.1 messages. +- __Octet__: An 8-bit byte. ### 1.3 Conventions @@ -247,6 +248,8 @@ SubjectPublicKeyInfo ::= SEQUENCE { } ``` +See Section 4 for more information about what public key algorithms should be used and supported. + #### 2.1.2.8 `issuerUniqueID` and `subjectUniqueID` Optional identifiers uniquely associated with the issuer or subject of the certificate. @@ -267,115 +270,77 @@ Extension ::= SEQUENCE { } ``` -### 2.1 CA Certificates - -#### 2.1.1 Validity - -TODO: Write something about sensible validity periods for certs. +| Extension | OID | Brief Description | +|:-----------------------------|:------------|:------------------| +| Authority Key Identifier | `2.5.29.35` | +| Subject Key Identifier | `2.5.29.14` | +| Key Usage | `2.5.29.15` | +| Certificate Policies | `2.5.29.32` | +| Policy Mappings | `2.5.29.33` | +| Subject Alternative Name | `2.5.29.17` | +| Issuer Alternative Name | `2.5.29.18` | +| Subject Directory Attributes | `2.5.29.9` | +| Basic Constraints | `2.5.29.19` | +| Name Constraints | `2.5.29.30` | _Must not_ be used. +| Policy Constraints | `2.5.29.36` | +| Extended Key Usage | `2.5.29.37` | +| CRL Distribution Points | `2.5.29.31` | -#### 2.1.2 Subject -| RDN | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | +### 2.2 CA Certificates -#### 2.1.3 Extensions +#### 2.2.1 Common Field Constraints -| Extension | OID | Critical | Value | -|:-----------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: n*` | -| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | - -* each profile specifies its own `n`. - -### 2.2 End Entity Certificates - -#### 2.2.1 Validity +#### 2.2.1.1 `validity` TODO: Write something about sensible validity periods for certs. -#### 2.2.2 Subject +#### 2.2.1.2 `subject` -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -__Entity naming__. -Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. -While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. -The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). -Concretely, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. -This means that full domain names are _not_ allowed as subject CN, such as `my-device.company.arrowhead.eu`. -In the case of that example, it should rather have been `my-device`. -Full domain names are specified as subject alternative names where relevant. - -#### 2.2.3 Extensions +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | +#### 2.2.1.3 `extensions` -### 2.3 Transfer Certificates +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | hash(Issuer.`subjectPublicKeyInfo`.`subjectPublicKey`) | +| Subject Key Identifier | `2.5.29.14` | No | hash(`subjectPublicKeyInfo`.`subjectPublicKey`) | +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: n*` | +| Key Usage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | -## 3. Arrowhead X.509 Profiles +* each profile specifies its own `n`. -### 3.1 Master +### 2.2.2 Profiles -#### 3.1.1 Issuer +#### 2.2.2.1 Master Issued by any suitable RFC 5280 certificate, or none at all (self-signed). -#### 3.1.2 Validity +Validity? -#### 3.1.3 Subject +`subject` -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | DN Qualifier (DN) | `2.5.4.46` | Yes | `master` | -#### 2.1.3 Extensions +`extensions` | Extension | OID | Critical | Value | |:-----------------|:------------|:---------|:------| | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2` | -### 3.2 Gate - - +### 2.2.2.2 Organization Issued by a _Master_ certificate. -#### Subject - -| RDN | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | `gate` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | - -### 3.3 Organization - -#### Issuer - -A _Master_ certificate. - -#### Subject +Validity -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DN) | `2.5.4.46` | Yes | `organization` | @@ -396,7 +361,7 @@ An _Organization_ certificate. #### Subject -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | DN Qualifier (DN) | `2.5.4.46` | Yes | `localcloud` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -408,6 +373,43 @@ An _Organization_ certificate. | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0` | | KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | + +### 2.3 End Entity Certificates + +#### 2.2.1 `validity` + +TODO: Write something about sensible validity periods for certs. + +#### 2.2.2 `subject` + +| Attribute Type | OID | Required | Value | +|:------------------|:-----------|:---------|:------| +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | +| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | + +__Entity naming__. +Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. +The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). +Concretely, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. +This means that full domain names are _not_ allowed as subject CN, such as `my-device.company.arrowhead.eu`. +In the case of that example, it should rather have been `my-device`. +Full domain names are specified as subject alternative names where relevant. + +#### 2.2.3 `extensions` + +| Extension | OID | Critical | Value | +|:------------------------|:------------|:---------|:------| +| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | +| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | + +### 2.3 Transfer Certificates + +## 3. Arrowhead X.509 Profiles + + ### 3.5 On-Boarding #### Issuer @@ -416,7 +418,7 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | DN Qualifier (DN) | `2.5.4.46` | Yes | `onboarding` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -437,7 +439,7 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | DN Qualifier (DN) | `2.5.4.46` | Yes | `device` | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | @@ -458,7 +460,7 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | | DN Qualifier (DN) | `2.5.4.46` | Yes | `system` | @@ -480,7 +482,7 @@ A _Local Cloud_ certificate. #### Subject -| RDN | OID | Required | Value | +| Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | DN Qualifier (DN) | `2.5.4.46` | Yes | `operator` | | Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | @@ -525,3 +527,8 @@ However, as mobility at a scale that makes this setup a problem are currently de It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. ## References + +| Extension | OID | Critical | Value | +|:-----------------|:------------|:---------|:------| +| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1` | +| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | \ No newline at end of file From 8affe5d359c688e8e710024849b90fa23ad95245 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Tue, 17 Aug 2021 15:31:29 +0200 Subject: [PATCH 12/36] Work on proposal.md --- proposal.md | 338 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 224 insertions(+), 114 deletions(-) diff --git a/proposal.md b/proposal.md index 896645a..44ae36d 100644 --- a/proposal.md +++ b/proposal.md @@ -2,8 +2,7 @@ ## Abstract -This document specifies how X.509 certificates must be configured and issued to facilitate secure communication and identification within Eclipse Arrowhead local clouds. -It describes the certificates of Certificate Authorities (CAs) and end entities, relevant certificate security details, recommended procedures for the creation and distribution of certificates, as well as how DNS overlaps with X.509 in the context of Arrowhead. +This document specifies how X.509 certificates are to be configured, issued and validated to facilitate secure identification and communication within and between Eclipse Arrowhead local clouds, when such security is desired and the kind of certificate is relevant. ## 1. Introduction @@ -11,25 +10,20 @@ TODO ### 1.1 Relation to the IETF RFC 5280 X.509 Profile -All certificate profiles in this document, with the exception of the _Manufacturer_ and _Transfer_ profiles of Sections 3.9 and 3.10, are meant to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. -Most significantly, this makes our profiles compatible with many implementations the TLS and DTLS standards for secure communication, even though complying to this document will require additional validation steps, such as ensuring that certain extensions are being or not being used. -Those steps are outlined in Section 6. - -Building on top of RFC 5280 and X.509 means that also X.501 and ASN.1 become relevant to this document, as those standards define the subject/issuer naming schema and syntax notation used by X.509. -In particular, the interface description language of ASN.1 is used here to describe relevant certificate constituents. -Please refer to ASN.1 or a relevant learning resource if wanting to know more about its syntax. +All certificate profiles in this document, with the exception of the _Manufacturer_ and _Transfer_ profiles of Sections X and Y, are _required_ to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. +Most significantly, this makes our profiles compatible with many implementations of the TLS and DTLS standards for secure communication, as well as many with many web programming frameworks. ### 1.2 Significant Terminology The following subsections represent technical domains with particular bearing on this document. -Each subsection briefly describes the domain and lists terms relevant to our purposes. +Each subsection briefly describes the domain and lists terms and abbreviations relevant to our purposes. #### 1.2.1 Eclipse Arrowhead Service-oriented architecture for Industry 4.0 automation. - __Device__: A physical machine that could be capable of hosting Arrowhead _systems_. -- __Local Cloud__: A physical or logical protected network consisting of communicating _systems_. +- __Local Cloud__: A physical protected network consisting of communicating _systems_. - __Service__: An explicitly defined network application interface accessible to authorized _systems_. - __System__: A software application providing Arrowhead-compliant _services_ that runs on a _device_. @@ -38,6 +32,8 @@ Service-oriented architecture for Industry 4.0 automation. Certificate standard for establishing trust between devices over untrusted computer networks. - __Certificate Authority (CA)__: Entity issuing (signing) other certificates to endorse their validity. +- __Certificate Chain__: A chain consisting of an _end entity_ certificate, its _issuer_'s certificate, that _issuer_'s _issuer_'s certificate, and so on up to the _root CA_'s certificate. +- __Certificate Revocation List (CRL)__: A list of certificates, maintained their _issuer_, that identifies certificates who no longer are to be considered valid, even though they are yet to expire. - __End Entity__: Entity having but not issuing certificates. - __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. - __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. @@ -45,12 +41,12 @@ Certificate standard for establishing trust between devices over untrusted compu - __Public Key Infrastructure (PKI)__: The structure of entities, each having a certain role, required to facilitate secure certificate distribution. - __Root CA__: CA that _did_ issue (self-sign) its own certificate and, therefore, must be explicitly trusted. - __Subject__: The entity owning and being described by a given certificate. -- __Trust Anchor__: Another name for _Root CA_. +- __Trust Anchor__: Another name for _root CA_. #### 1.2.3 X.501 Naming schema for X.500 directories. -The standard is used to name X.509 certificates. +The standard is used to name the subjects and issuers of X.509 certificates. - __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. The comma character `,` is used to delimit the RDNs. - __Relative Distinguished Name (RDN)__: A list of attribute/value pairs belonging to the same hierarchical level in a DN. Examples of RDNs could be `O=My Company` and `CN=Robert Robertson+E=robert@mail.com`. The first RDN consists of a single pair while the second consists of two delimited by `+`. @@ -58,7 +54,7 @@ The standard is used to name X.509 certificates. #### 1.2.4 ASN.1 Interface description language for describing messages that can be sent or received over computer networks using several associated encodings. -The standard is used to describe the structure of X.509 certificates, which must be encoded using ASN.1 DER, as defined below. +The standard is used to describe the structure of X.509 certificates, which _must_ be encoded using ASN.1 DER, as defined below. - __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends basic type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 description. Defined in X.690. - __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation, which is to say that every pair of structurally equivalent ASN.1 messages can be represented in DER in exactly one way. Must be used when encoding X.509 certificates. Defined in X.690. @@ -67,17 +63,20 @@ The standard is used to describe the structure of X.509 certificates, which must ### 1.3 Conventions -The words __must__, __must not__, __required__, __shall__, __shall not__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as described in IETF RFC 2119. -In short, this means that __must__, __required__ and __shall__ denote absolute requirements; __must not__ and __shall not__ denote absolute prohibitions; __should__, __should not__ and __recommended__ denote recommendations; and, finally, __may__ and __optional__ denote the subject of concern being truly optional. +The words __must__, __must not__, __required__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as follows: __must__ and __required__ denote absolute requirements that must be adhered to by profile adherents; __must not__ denotes an absolute prohibition; __should__, __should not__ and __recommended__ denote recommendations that should be deviated from only if special circumstances make it relevant; and, finally, __may__ and __optional__ denote something being truly optional. ## 2. Certificate Profiles TODO -## 2.1 Basic Certificate Fields +## 2.1 Certificate Format + +This section introduces the X.509 certificate format in its ASN.1 syntax. +It describes each of its fields and states how they should be used, if at all, by conforming certificates. +It does not rigorously define all fields, however. +Advanced learners and certificate software implementors should consult the official sources for more details. -The X.509 version 3 certificate has the below ASN.1 syntax, as defined in RFC 5280. -Note that RFC 5280 demands that the certificate be encoded using DER. +The ASN.1 syntax of the third version of the X.509 certificate is defined in as follows in RFC 5280: ```asn1 Certificate ::= SEQUENCE { @@ -100,62 +99,40 @@ Note that RFC 5280 demands that the certificate be encoded using DER. } ``` -In this section, we will go through each of these fields and clarify what they signify and how they must or may be set in conforming Arrowhead X.509 certificates. -The section is by no means an attempt to rigorously define these fields. -Please consult RFC 5280 and X.509 for more exact details. - -### 2.1.1 `Certificate` - -A certificate and its signature. - -#### 2.1.1.1 `tbsCertificate` - -The part of the certificate whose integrity is guaranteed by the `signatureAlgorithm` and `signatureValue` fields. - -#### 2.1.1.2 `signatureAlgorithm` - -The cryptographic signature algorithm used to produce `signatureValue` and any parameters made relevant by the algorithm type. -Examples of algorithms could be _RSA with SHA256_ or _ED25519_. +The `Certificate` structure itself consists only of a `TBSCertificate`, a signature algorithm identifier and a concrete signature. +The signature is meant to be produced by the issuer of the certificate and serves to protect the integrity of the certificate under the assumption that the issuer is trusted. +All data protected by the signature is collected in the `TBSCertificate`. +Each of its fields is described in the following subsections. -This field must contain the same algorithm as the `signature` field in the `tbsCertificate`, as described in Section 2.1.2.3. - -#### 2.1.1.3 `signatureValue` - -A string of arbitrary bytes whose length is determined by the output of the `signatureAlgorithm`. -The value is used together with `signatureAlgorithm` and the public key of the issuer of the certificate to validate its integrity. - -### 2.1.2 `TBSCertificate` - -A certificate covered by, but not including, a signature. - -#### 2.1.2.1 `version` +#### 2.1.1 `version` X.509 version of the certificate. -Must always be `v3(2)`. - -RFC 5280 recommends that `v1(0)` and `v2(1)` certificates be used when the additional fields of later versions are unused. -It does only require that `v3(2)` be supported, however. -As we rely on certificate extensions for all of our profiles, we always require `v3(2)`. +Must be `v3(2)` for all certificates that utilize certificate extensions, as described in Section 2.1.9. +Supporting `v1(0)` and `v2(1)` at all is _optional_. -#### 2.1.2.2 `serialNumber` +#### 2.1.2 `serialNumber` A positive integer of no more than 20 octets uniquely assigned by the issuer of the certificate. -__Recommendation__. +__Security recommendation__. The serial number should be exactly 20 octets long and be produced by a cryptographic random number generator. This serves both to (A) make the certificate more resistant to collision attacks and (B) to prevent the serial number from leaking important details about the certificate issuer, such as how many certificates it has issued, how long the signing process took, and so on. -Note that the number is signed and must be positive, which means that the most significant bit of the first DER `INTEGER` octet must be 0. +If certificate size would be a major concern, for example when certificates are used by significantly constrained devices, fewer octets _may_ be used. +Note that the serial number is signed and must be positive, which means that the most significant bit of its first ASN.1 BER `INTEGER` octet must be 0. -#### 2.1.2.3 `signature` +#### 2.1.3 `signature` + +An identifier associated with the cryptographic signature algorithm used to produce the `signatureValue` in the enclosing `Certificate`, as well as any parameters made relevant by the algorithm type. +Examples of algorithms could be _RSA with SHA256_ or _ED25519_. -This field must contain the same algorithm as the `signatureAlorithm` field in the `Certificate`, as described in Section 2.1.1.2. +This field must contain the same algorithm as the `signatureAlorithm` field in the enclosing `Certificate`, as described in the beginning of Section 2.1. -#### 2.1.2.4 `issuer` +#### 2.1.4 `issuer` The DN of the issuer of the certificate in question. -More specifically, this field contains an exact copy of the `subject` field of Section 2.1.2.6 from the certificate of its issuer. +More specifically, this field contains an exact copy of the `subject` field of Section 2.1.6 from the certificate of its issuer. -#### 2.1.2.5 `validity` +#### 2.1.5 `validity` The period during which the certificate _may_ remain active and its issuer is bound to know whether or not the certificate has been revoked or not. Denoted as a duration between two timestamps, `notBefore` and `notAfter`, as show below. @@ -175,14 +152,14 @@ Time ::= CHOICE { For each of these two dates, the date in question _must_ be encoded as a `UTCTime` if its year is less than or equal to 2049, or as a `GeneralizedTime` if the year is equal to or greater than 2050. More details about the validity format may be read in Section 4.1.2.5 of RFC 5280. -#### 2.1.2.6 `subject` +#### 2.1.6 `subject` The DN used to describe the owner of the certificate. The field is defined as follows: ```asn1 Name ::= CHOICE { - rdnSequence RDNSequence + rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName @@ -190,8 +167,8 @@ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue + type AttributeType, + value AttributeValue } AttributeType ::= OBJECT IDENTIFIER @@ -201,15 +178,18 @@ AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DirectoryString ::= CHOICE { - teletexString TeletexString (SIZE (1..MAX)), - printableString PrintableString (SIZE (1..MAX)), -- ASCII subset. Preferred. - universalString UniversalString (SIZE (1..MAX)), - utf8String UTF8String (SIZE (1..MAX)), -- Use when `PrintableString` is insufficient. - bmpString BMPString (SIZE (1..MAX)) + teletexString TeletexString (SIZE (1..MAX)), + printableString PrintableString (SIZE (1..MAX)), + universalString UniversalString (SIZE (1..MAX)), + utf8String UTF8String (SIZE (1..MAX)), + bmpString BMPString (SIZE (1..MAX)) } ``` -The below `AttributeType`s must be supported, in the sense that their OIDs are known to be associated with values of type `DirectoryString`, as defined above. +The below `AttributeType`s _must_ be supported by compliant software implementations, as required by RFC 5280. +Supporting them means that that their OIDs are known to be associated with values of type `DirectoryString`, as defined above. +Failing to support them means that the certificate validation procedure of RFC 5280, Section 6, cannot be executed. +See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. | Attribute Type | Abbreviation | OID | |:-----------------------------|:-------------|:----| @@ -222,43 +202,32 @@ The below `AttributeType`s must be supported, in the sense that their OIDs are k | Serial Number | `SN` | `2.5.4.5` | State or Province Name | `ST` | `2.5.4.8` -In contrast to RFC 5280, we _require_ always that each `AttributeValue` associated with any type of this list is concretely represented as a `PrintableString` or a `UTF8String`. -The former is preferred when its limited character set is sufficient. -See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. - -__Precedence__. -Being _hierarchical_, a DN describes a path from some arbitrary root to the subject or issuer in question, where the root is the leftmost RDN and the subject or issuer is the rightmost. -The root does not have to be associated with the Root CA of the certificate in question. -While the above listed attributes _should not_ appear more than once in a subject or issuer DN, if they do, the rightmost takes precedence during the authorization procedure described in Section 6. - -__Recommendation__. -Every certificate implementing a Section 3 profile _should_ only contain the attributes associated with that profile. -Each attribute _should_ be contained in its own RDN, and the RDNs _should_ be in the same order as they are presented in Section 3. -If a Section 3 attribute is declared as not required, it _may_ be omitted. - -#### 2.1.2.7 `subjectPublicKeyInfo` +#### 2.1.7 `subjectPublicKeyInfo` The public key of the subject, as well as the identity of the algorithm associated with it. The field is defined as follows. ```asn1 SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING } ``` -See Section 4 for more information about what public key algorithms should be used and supported. +See Section 3 for more information about what public key algorithms should be used and supported. -#### 2.1.2.8 `issuerUniqueID` and `subjectUniqueID` +#### 2.1.8 `issuerUniqueID` and `subjectUniqueID` Optional identifiers uniquely associated with the issuer or subject of the certificate. These fields _must not_ be used. -When a certain certificate, or its subject, needs to be identified, the cryptographic hash, or _fingerprint_, of the certificate _should_ be used. -See Section 4 for more information about what hashing algorithms should be used for this and other purposes. +When a certain certificate, or its subject, needs to be identified, the cryptographic hash of the certificate, or its _fingerprint_, _should_ be used. +If desired to identify the subject by its public key, which _may_ be used in multiple certificates, the cryptographic hash of the value bytes of the `subjectPublicKey` field of `subjectPublicKeyInfo` _should_ be used. +See Section 3 for more information about what hashing algorithms should be used for this and other purposes. + +#### 2.1.9 `extensions` -#### 2.1.2.9 `extensions` +A list of certificate extensions, as defined below. ```asn1 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension @@ -270,22 +239,158 @@ Extension ::= SEQUENCE { } ``` -| Extension | OID | Brief Description | -|:-----------------------------|:------------|:------------------| -| Authority Key Identifier | `2.5.29.35` | -| Subject Key Identifier | `2.5.29.14` | -| Key Usage | `2.5.29.15` | -| Certificate Policies | `2.5.29.32` | -| Policy Mappings | `2.5.29.33` | -| Subject Alternative Name | `2.5.29.17` | -| Issuer Alternative Name | `2.5.29.18` | -| Subject Directory Attributes | `2.5.29.9` | -| Basic Constraints | `2.5.29.19` | -| Name Constraints | `2.5.29.30` | _Must not_ be used. -| Policy Constraints | `2.5.29.36` | -| Extended Key Usage | `2.5.29.37` | -| CRL Distribution Points | `2.5.29.31` | +RFC 5280 explicitly outlines 17 different X.509 extensions, listed below. +They are categorized for the sake of clarity. + +| Extension | `extnID` (OID) | Brief Description | +|:-----------------------------|:---------------------|:------------------| +| _Key Extensions_ | | +| Authority Key Identifier | `2.5.29.35` | Identifier uniquely associated with certificate issuer. +| Subject Key Identifier | `2.5.29.14` | Identifier uniquely associated with certificate subject. +| Key Usage | `2.5.29.15` | Public key usage restrictions. +| Extended Key Usage | `2.5.29.37` | Additional public key usage restrictions. +| _Policy Extensions_ | | +| Certificate Policies | `2.5.29.32` | List of policies accepted by the certificate subject. +| Policy Mappings | `2.5.29.33` | List of policy equivalence relations. +| Policy Constraints | `2.5.29.36` | Policy validation constraints (e.g. policy X must be accepted). +| Inhibit `anyPolicy` | `2.5.29.54` | Policy validation constraint related to use of `anyPolicy`. +| _Name Extensions_ | | +| Subject Alternative Name | `2.5.29.17` | Additional names associated with the certificate subject. +| Issuer Alternative Name | `2.5.29.18` | Additional names associated with the certificate issuer. +| Name Constraints | `2.5.29.30` | List of subject name restrictions for issued certificates. +| _CRL Extensions_ | | +| CRL Distribution Points | `2.5.29.31` | List of where relevant CRLs can be found. +| Freshest CRL | `2.5.29.46` | List of where delta CRLs can be found. +| _Information Extensions_ | | +| Authority Information Access | `1.3.6.1.5.5.7.1.1` | List of where issuer information and services can be found. +| Subject Information Access | `1.3.6.1.5.5.7.1.11` | List of where subject information and services can be found. +| _Other Extensions_ | | +| Subject Directory Attributes | `2.5.29.9` | Additional subject identification attributes (e.g. nationality). +| Basic Constraints | `2.5.29.19` | Description of where a certificate belongs in its CA hierarchy. + +Each category of extensions is described in the following subsections. + +#### 2.1.9.1 Key Extensions + +The _Authority Key Identifier_ and _Subject Key Identifier_ extensions are used to identify the public key of the issuer and subject of a given certificate, respectively. +The extensions are defined as follows: + +```asn1 +-- Required for all but self-signed CA certificates. +AuthorityKeyIdentifier ::= SEQUENCE { + keyIdentifier [0] KeyIdentifier OPTIONAL, -- Required. + authorityCertIssuer [1] GeneralNames OPTIONAL, -- Optional. + authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL -- Optional. +} + +-- Required for all but end entity certificates. +SubjectKeyIdentifier ::= KeyIdentifier + +KeyIdentifier ::= OCTET STRING +``` + +RFC 5280 _requires_ that `AuthorityKeyIdentifier` extension is included in all CA certificates except for self-signed such. +The `keyIdentifier` of the `AuthorityKeyIdentifier` extension of a given certificate _must_ match the `SubjectKeyIdentifier` of its issuer's certificate, or _may_ be omitted if the certificate is self-signed. +Use of the `authorityCertIssuer` and `authorityCertSerialNumber` fields of `AuthorityKeyIdentifier` is optional. +If a self-signed certificate leaves the `authorityCertIssuer` and `authorityCertSerialNumber` fields unspecified, it may omit the `AuthorityKeyIdentifier` extension entirely. +RFC 5280 further _requires_ that all but end entity certificates use the `SubjectKeyIdentifier` extension. +Its value _should_ be the the cryptographic hash of the `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field. + +The _Key Usage_ and _Extended Key Usage_ extensions are defined as follows: + +```asn1 +KeyUsage ::= BIT STRING { + digitalSignature (0), + nonRepudiation (1), -- Also known as `contentCommitment`. + keyEncipherment (2), + dataEncipherment (3), + keyAgreement (4), + keyCertSign (5), + cRLSign (6), + encipherOnly (7), + decipherOnly (8) +} + +ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId + +KeyPurposeId ::= OBJECT IDENTIFIER +``` + +The `KeyUsage` extension is a set of bit flags used to indicate various ways in which a certificate _may_ be used. +Please refer to RFC 5280 Section 4.2.1.3 for descriptions of each bit flag. + +The `ExtKeyUsageSyntax` extension has the same purpose, but is open-ended in the sense that it allows for any OID to be used as an indication of what a certain certificate _may_ be used for. +RFC 5280 lists six such identifiers, out of which two has particular bearing on this document, namely the `serverAuth` (OID `1.3.6.1.5.5.7.3.1`) and `clientAuth` (OID `1.3.6.1.5.5.7.3.2`) identifiers, which indicate that the certificate holder should be allowed to act as a World Wide Web TLS server and client, respectively. + +#### 2.1.9.2 Policy Extensions + +In the context of X.509 and RFC 5280, a _policy_ is a legal document that binds the owner of a certificate and, potentially, all certificates issued by that certificate to certain legal obligations. +The four policy extensions defined by RFC 5280 _may_ be used to ensure that every certificate in a given certificate chain have accepted some policies of concern. +Please refer to RFC 5280 for more details about these extensions. +Their use is _optional_. + +#### 2.1.9.3 Name Extensions + +The _Subject Alternative Name_ and _Issuer Alternative Name_ allows for additional identities to be associated with a given `subject` or `issuer` name. +Such additional identities significantly include DNS names, IP addresses and e-mail addresses. +For example, given that some system receives a signed message and the certificate associated with that signature, the system can verify that it received the message via one of the identities listed as subject alternative name in that certificate. +The extensions are defined as follows: + +```asn1 +SubjectAltName ::= GeneralNames +IssuerAltName ::= GeneralNames + +GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName + +GeneralName ::= CHOICE { + otherName [0] OtherName, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] ORAddress, + directoryName [4] Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER +} +``` + +The _Name Constraints_ extension makes it possible for a CA to restrict the set of allowed `subject` and `SubjectAltName` that may be specified in certificates it issues. +Please refer to RFC 5280 Section 4.2.1.10 for more details. +#### 2.1.9.4 CRL Extensions + +The CRL extensions facilitate a mechanism for revoking certificates that are still valid and distributing information about those revocations. +These extensions _should not_ be used to facilitate the revocation of end entity certificates. +They _may_ be used for revoking CA certificates. + +Eclipse Arrowhead comes with its own certificate revocation procedure via its _Certificate Authority_ system. +Its use is _recommended_ for revoking and verifying the validity of end entity certificates. + +#### 2.1.9.5 Information Extension + +The information extensions allows various types of data sources or services to be associated with the certificate holder. +These extensions _should not_ be used. + +Eclipse Arrowhead a service-oriented architecture with its own provisions for metadata and service management. +Those provisions _should_ be used when possible. + +#### 2.1.9.6 Other Extensions + +The _Subject Directory Attributes_ allows for arbitrary identification attributes, such as nationality, to be associated with the `subject` of a certificate. +It _may_ be used. + +The _Basic Constraints_ extension allows for it to be denoted whether or not a given certificate belongs to a CA, as well as how many intermediary CAs may exist below it in any given certificate chain. +The extension is defined as follows: + +```asn1 +BasicConstraints ::= SEQUENCE { + cA BOOLEAN DEFAULT FALSE, + pathLenConstraint INTEGER (0..MAX) OPTIONAL +} +``` + +The extension _must_ be used by all Arrowhead-compliant certificates. ### 2.2 CA Certificates @@ -507,23 +612,28 @@ Any or none at all. A _Manufacturer_ certificate. -## 4. Algorithms, Key Lengths and Other Security Details +## 3. Algorithms, Key Lengths and Other Security Details - Use fingerprints to identify certificate owners, not subject names. -## 5. Certificate Creation and Distribution +## 4. Certificate Creation and Distribution -## 6. Authentication and Authorization +## 5. Authentication and Authorization + +__Precedence__. +Being _hierarchical_, a DN describes a path from some arbitrary root to the subject or issuer in question, where the root is the leftmost RDN and the subject or issuer is the rightmost. +The root does not have to be associated with the root CA of the certificate in question. +While the above listed attributes _should not_ appear more than once in a subject or issuer DN, if they do, the rightmost takes precedence during the authorization procedure described in Section 6. -## 7. DNS Support and its Security Implications +## 6. DNS Support and its Security Implications -## 8. Known Limitations +## 7. Known Limitations -### 8.1 Subject Alternative Names and Device Mobility +### 7.1 Subject Alternative Names and Device Mobility Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. -However, as mobility at a scale that makes this setup a problem are currently deemed of marginal utility, no provisions are given for it directly. +However, as mobility at a scale that makes this setup a problem is currently deemed of marginal utility, no provisions are given for it directly. It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. ## References From b5a248fb65d3164f21f52bc67b35353803e13c53 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Tue, 17 Aug 2021 16:37:09 +0200 Subject: [PATCH 13/36] Work on proposal.md --- proposal.md | 88 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 65 insertions(+), 23 deletions(-) diff --git a/proposal.md b/proposal.md index 44ae36d..b320501 100644 --- a/proposal.md +++ b/proposal.md @@ -244,27 +244,27 @@ They are categorized for the sake of clarity. | Extension | `extnID` (OID) | Brief Description | |:-----------------------------|:---------------------|:------------------| -| _Key Extensions_ | | +| __Key Extensions__ | | | Authority Key Identifier | `2.5.29.35` | Identifier uniquely associated with certificate issuer. | Subject Key Identifier | `2.5.29.14` | Identifier uniquely associated with certificate subject. | Key Usage | `2.5.29.15` | Public key usage restrictions. | Extended Key Usage | `2.5.29.37` | Additional public key usage restrictions. -| _Policy Extensions_ | | +| __Policy Extensions__ | | | Certificate Policies | `2.5.29.32` | List of policies accepted by the certificate subject. | Policy Mappings | `2.5.29.33` | List of policy equivalence relations. | Policy Constraints | `2.5.29.36` | Policy validation constraints (e.g. policy X must be accepted). | Inhibit `anyPolicy` | `2.5.29.54` | Policy validation constraint related to use of `anyPolicy`. -| _Name Extensions_ | | +| __Name Extensions__ | | | Subject Alternative Name | `2.5.29.17` | Additional names associated with the certificate subject. | Issuer Alternative Name | `2.5.29.18` | Additional names associated with the certificate issuer. | Name Constraints | `2.5.29.30` | List of subject name restrictions for issued certificates. -| _CRL Extensions_ | | +| __CRL Extensions__ | | | CRL Distribution Points | `2.5.29.31` | List of where relevant CRLs can be found. | Freshest CRL | `2.5.29.46` | List of where delta CRLs can be found. -| _Information Extensions_ | | +| __Information Extensions__ | | | Authority Information Access | `1.3.6.1.5.5.7.1.1` | List of where issuer information and services can be found. | Subject Information Access | `1.3.6.1.5.5.7.1.11` | List of where subject information and services can be found. -| _Other Extensions_ | | +| __Other Extensions__ | | | Subject Directory Attributes | `2.5.29.9` | Additional subject identification attributes (e.g. nationality). | Basic Constraints | `2.5.29.19` | Description of where a certificate belongs in its CA hierarchy. @@ -391,37 +391,79 @@ BasicConstraints ::= SEQUENCE { ``` The extension _must_ be used by all Arrowhead-compliant certificates. +The `pathLenConstraint` _must_ be set by all CA certificates. -### 2.2 CA Certificates +### 2.2 Certificate Hierarchy -#### 2.2.1 Common Field Constraints +There are eight _primary_ and two _secondary_ certificate profiles defined in this document, depicted in the diagram further below. +The boxes of the diagram represent certificate profiles. +The arrows in the diagram are to be read as "issued by", meaning that the certificate profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. -#### 2.2.1.1 `validity` +``` + Secondary Primary + + + - - - - - - - + + . (Root) . + + - - - - - - - + + A + . + . + +---------------+ + | Master | + +---------------+ + A + | + +--------------------+ + | | + +-------+-------+ +-------+-------+ + | Organization | | Gate | + +---------------+ +---------------+ + A + | ++-------+-------+ +-------+-------+ +| Manufacturer | | Local Cloud | ++---------------+ +---------------+ + A A + | | + | +-----------------+--------+--------+-----------------+ + | | | | | ++-------+-------+ +------+------+ +------+------+ +------+------+ +------+------+ +| Transfer | | On-Boarding | | Device | | System | | Operator | End Entity Certificates ++---------------+ +-------------+ +-------------+ +-------------+ +-------------+ +``` + +The certificate constraints presented throughout the rest of this section only apply to the primary certificates. +The secondary certificates are considered only for their indirect relation to the _On-Boarding_ certificate. +Their only constraints are that the _Manufacturer_ certificate _must_ have issued the _Transfer_ certificate and that they pass all basic X.509 validation checks. + +### 2.3 CA Certificates + +#### 2.3.1 Common Fields + +#### 2.3.1.1 `validity` TODO: Write something about sensible validity periods for certs. -#### 2.2.1.2 `subject` +#### 2.3.1.2 `subject` | Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | +| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. +| DN Qualifier (DN) | `2.5.4.46` | Yes | _Profile identifier_ specific to each certificate profile. +| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. -#### 2.2.1.3 `extensions` +#### 2.3.1.3 `extensions` | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Authority Key Identifier | `2.5.29.35` | No | hash(Issuer.`subjectPublicKeyInfo`.`subjectPublicKey`) | -| Subject Key Identifier | `2.5.29.14` | No | hash(`subjectPublicKeyInfo`.`subjectPublicKey`) | -| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: n*` | -| Key Usage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | - -* each profile specifies its own `n`. +| Authority Key Identifier | `2.5.29.35` | No | See Section 2.1.9.1. +| Subject Key Identifier | `2.5.29.14` | No | See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | See Section 2.1.9.6. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. -### 2.2.2 Profiles +### 2.3.2 Profiles -#### 2.2.2.1 Master +#### 2.3.2.1 Master Issued by any suitable RFC 5280 certificate, or none at all (self-signed). @@ -439,7 +481,7 @@ Validity? |:-----------------|:------------|:---------|:------| | BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2` | -### 2.2.2.2 Organization +### 2.3.2.2 Organization Issued by a _Master_ certificate. From 5fc75416ec21ce508a0fb3b77706de4e2eedfbb7 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 18 Aug 2021 16:11:20 +0200 Subject: [PATCH 14/36] Work on proposal.md --- proposal.md | 57 +++++++++++++++++++++++------------------------------ 1 file changed, 25 insertions(+), 32 deletions(-) diff --git a/proposal.md b/proposal.md index b320501..41f31d4 100644 --- a/proposal.md +++ b/proposal.md @@ -11,12 +11,11 @@ TODO ### 1.1 Relation to the IETF RFC 5280 X.509 Profile All certificate profiles in this document, with the exception of the _Manufacturer_ and _Transfer_ profiles of Sections X and Y, are _required_ to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. -Most significantly, this makes our profiles compatible with many implementations of the TLS and DTLS standards for secure communication, as well as many with many web programming frameworks. ### 1.2 Significant Terminology The following subsections represent technical domains with particular bearing on this document. -Each subsection briefly describes the domain and lists terms and abbreviations relevant to our purposes. +Each subsection briefly describes a domain and defines relevant terms and abbreviations. #### 1.2.1 Eclipse Arrowhead @@ -400,36 +399,30 @@ The boxes of the diagram represent certificate profiles. The arrows in the diagram are to be read as "issued by", meaning that the certificate profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. ``` - Secondary Primary - - + - - - - - - - + - . (Root) . - + - - - - - - - + - A - . - . - +---------------+ - | Master | - +---------------+ - A - | - +--------------------+ - | | - +-------+-------+ +-------+-------+ - | Organization | | Gate | - +---------------+ +---------------+ - A - | -+-------+-------+ +-------+-------+ -| Manufacturer | | Local Cloud | -+---------------+ +---------------+ - A A - | | - | +-----------------+--------+--------+-----------------+ - | | | | | -+-------+-------+ +------+------+ +------+------+ +------+------+ +------+------+ -| Transfer | | On-Boarding | | Device | | System | | Operator | End Entity Certificates -+---------------+ +-------------+ +-------------+ +-------------+ +-------------+ + Secondary Primary + ++--------------+ +---------------+ +| Manufacturer | | Master | ++--------------+ +---------------+ + A A + | | + | +--------------------+ + | | | + | +-------+-------+ +-------+-------+ + | | Organization | | Gate | + | +---------------+ +---------------+ + | A + | | + | +-------+-------+ + | | Local Cloud | + | +---------------+ + | A + | | + | +-----------------+--------+--------+-----------------+ + | | | | | ++------+------+ +------+------+ +------+------+ +------+------+ +------+------+ +| Transfer | | On-Boarding | | Device | | System | | Operator | ++-------------+ +-------------+ +-------------+ +-------------+ +-------------+ ``` The certificate constraints presented throughout the rest of this section only apply to the primary certificates. From 4d094209b7a2665ecda7ad9e4a892a813bd26100 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 18 Aug 2021 16:22:48 +0200 Subject: [PATCH 15/36] Work on proposal.md --- proposal.md | 88 +++++++++++++++++++++++++---------------------------- 1 file changed, 41 insertions(+), 47 deletions(-) diff --git a/proposal.md b/proposal.md index 41f31d4..5260352 100644 --- a/proposal.md +++ b/proposal.md @@ -10,7 +10,7 @@ TODO ### 1.1 Relation to the IETF RFC 5280 X.509 Profile -All certificate profiles in this document, with the exception of the _Manufacturer_ and _Transfer_ profiles of Sections X and Y, are _required_ to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. +All certificate profiles specified in this document are _required_ to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. ### 1.2 Significant Terminology @@ -66,13 +66,42 @@ The words __must__, __must not__, __required__, __should__, __should not__, __re ## 2. Certificate Profiles -TODO +There are eight certificate profiles defined in this document, depicted in the diagram further below. +Each diagram box represents a certificate profile. +The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. + +``` + +---------------+ + | Master | + +---------------+ + A + | + +--------------------+ + | | + +-------+-------+ +-------+-------+ + | Organization | | Gate | + +---------------+ +---------------+ + A + | + +-------+-------+ + | Local Cloud | + +---------------+ + A + | + +-----------------+--------+--------+-----------------+ + | | | | ++------+------+ +------+------+ +------+------+ +------+------+ +| On-Boarding | | Device | | System | | Operator | ++-------------+ +-------------+ +-------------+ +-------------+ +``` + +We begin by considering the X.509 format itself, after which we first consider the CA certificates (Master, Organization and Local Cloud) and then the end entity certificates (Gate, On-Boarding, Device, System and Operator). ## 2.1 Certificate Format -This section introduces the X.509 certificate format in its ASN.1 syntax. -It describes each of its fields and states how they should be used, if at all, by conforming certificates. -It does not rigorously define all fields, however. +In this section, we introduce the X.509 certificate format in its ASN.1 syntax. +We describes each of its fields and state how they should be used, if at all, by conforming certificates. +Our descriptions are not, however, rigorous enough to base real-world implementations on only them. Advanced learners and certificate software implementors should consult the official sources for more details. The ASN.1 syntax of the third version of the X.509 certificate is defined in as follows in RFC 5280: @@ -231,7 +260,7 @@ A list of certificate extensions, as defined below. ```asn1 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension -Extension ::= SEQUENCE { +Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING @@ -271,7 +300,7 @@ Each category of extensions is described in the following subsections. #### 2.1.9.1 Key Extensions -The _Authority Key Identifier_ and _Subject Key Identifier_ extensions are used to identify the public key of the issuer and subject of a given certificate, respectively. +The __Authority Key Identifier__ and __Subject Key Identifier__ extensions are used to identify the public key of the issuer and subject of a given certificate, respectively. The extensions are defined as follows: ```asn1 @@ -295,7 +324,7 @@ If a self-signed certificate leaves the `authorityCertIssuer` and `authorityCert RFC 5280 further _requires_ that all but end entity certificates use the `SubjectKeyIdentifier` extension. Its value _should_ be the the cryptographic hash of the `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field. -The _Key Usage_ and _Extended Key Usage_ extensions are defined as follows: +The __Key Usage__ and __Extended Key Usage__ extensions are defined as follows: ```asn1 KeyUsage ::= BIT STRING { @@ -330,7 +359,7 @@ Their use is _optional_. #### 2.1.9.3 Name Extensions -The _Subject Alternative Name_ and _Issuer Alternative Name_ allows for additional identities to be associated with a given `subject` or `issuer` name. +The __Subject Alternative Name__ and __Issuer Alternative Name__ allows for additional identities to be associated with a given `subject` or `issuer` name. Such additional identities significantly include DNS names, IP addresses and e-mail addresses. For example, given that some system receives a signed message and the certificate associated with that signature, the system can verify that it received the message via one of the identities listed as subject alternative name in that certificate. The extensions are defined as follows: @@ -354,7 +383,7 @@ GeneralName ::= CHOICE { } ``` -The _Name Constraints_ extension makes it possible for a CA to restrict the set of allowed `subject` and `SubjectAltName` that may be specified in certificates it issues. +The __Name Constraints__ extension makes it possible for a CA to restrict the set of allowed `subject` and `SubjectAltName` that may be specified in certificates it issues. Please refer to RFC 5280 Section 4.2.1.10 for more details. #### 2.1.9.4 CRL Extensions @@ -376,10 +405,10 @@ Those provisions _should_ be used when possible. #### 2.1.9.6 Other Extensions -The _Subject Directory Attributes_ allows for arbitrary identification attributes, such as nationality, to be associated with the `subject` of a certificate. +The __Subject Directory Attributes__ allows for arbitrary identification attributes, such as nationality, to be associated with the `subject` of a certificate. It _may_ be used. -The _Basic Constraints_ extension allows for it to be denoted whether or not a given certificate belongs to a CA, as well as how many intermediary CAs may exist below it in any given certificate chain. +The __Basic Constraints__ extension allows for it to be denoted whether or not a given certificate belongs to a CA, as well as how many intermediary CAs may exist below it in any given certificate chain. The extension is defined as follows: ```asn1 @@ -394,41 +423,6 @@ The `pathLenConstraint` _must_ be set by all CA certificates. ### 2.2 Certificate Hierarchy -There are eight _primary_ and two _secondary_ certificate profiles defined in this document, depicted in the diagram further below. -The boxes of the diagram represent certificate profiles. -The arrows in the diagram are to be read as "issued by", meaning that the certificate profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. - -``` - Secondary Primary - -+--------------+ +---------------+ -| Manufacturer | | Master | -+--------------+ +---------------+ - A A - | | - | +--------------------+ - | | | - | +-------+-------+ +-------+-------+ - | | Organization | | Gate | - | +---------------+ +---------------+ - | A - | | - | +-------+-------+ - | | Local Cloud | - | +---------------+ - | A - | | - | +-----------------+--------+--------+-----------------+ - | | | | | -+------+------+ +------+------+ +------+------+ +------+------+ +------+------+ -| Transfer | | On-Boarding | | Device | | System | | Operator | -+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ -``` - -The certificate constraints presented throughout the rest of this section only apply to the primary certificates. -The secondary certificates are considered only for their indirect relation to the _On-Boarding_ certificate. -Their only constraints are that the _Manufacturer_ certificate _must_ have issued the _Transfer_ certificate and that they pass all basic X.509 validation checks. - ### 2.3 CA Certificates #### 2.3.1 Common Fields From 93707dc95489f48301dc1e4abd8f450bf5cae83f Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 19 Aug 2021 10:20:17 +0200 Subject: [PATCH 16/36] Work on proposal.md --- proposal.md | 49 ++++++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/proposal.md b/proposal.md index 5260352..acb5c21 100644 --- a/proposal.md +++ b/proposal.md @@ -19,7 +19,7 @@ Each subsection briefly describes a domain and defines relevant terms and abbrev #### 1.2.1 Eclipse Arrowhead -Service-oriented architecture for Industry 4.0 automation. +Service-oriented communication architecture for Industry 4.0 automation. - __Device__: A physical machine that could be capable of hosting Arrowhead _systems_. - __Local Cloud__: A physical protected network consisting of communicating _systems_. @@ -32,7 +32,8 @@ Certificate standard for establishing trust between devices over untrusted compu - __Certificate Authority (CA)__: Entity issuing (signing) other certificates to endorse their validity. - __Certificate Chain__: A chain consisting of an _end entity_ certificate, its _issuer_'s certificate, that _issuer_'s _issuer_'s certificate, and so on up to the _root CA_'s certificate. -- __Certificate Revocation List (CRL)__: A list of certificates, maintained their _issuer_, that identifies certificates who no longer are to be considered valid, even though they are yet to expire. +- __Certificate Revocation List (CRL)__: A list identifying certificates that no longer are to be considered valid even though they are yet to expire. +- __Certificate Signing Request (CSR)__: A description of a desired certificate that can be sent to a CA. - __End Entity__: Entity having but not issuing certificates. - __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. - __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. @@ -47,7 +48,7 @@ Certificate standard for establishing trust between devices over untrusted compu Naming schema for X.500 directories. The standard is used to name the subjects and issuers of X.509 certificates. -- __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. The comma character `,` is used to delimit the RDNs. +- __Distinguished Name (DN)__: A hierarchical naming format composed consisting of RDNs. An example of a DN could be `O=My Company,CN=Robert Robertson+E=robert@mail.com`. The `O` RDN is at the highest hierarchical level, while the `CN+E` RDN is at the level below it. The comma character `,` is used to delimit the RDNs in this example. - __Relative Distinguished Name (RDN)__: A list of attribute/value pairs belonging to the same hierarchical level in a DN. Examples of RDNs could be `O=My Company` and `CN=Robert Robertson+E=robert@mail.com`. The first RDN consists of a single pair while the second consists of two delimited by `+`. #### 1.2.4 ASN.1 @@ -57,18 +58,16 @@ The standard is used to describe the structure of X.509 certificates, which _mus - __Basic Encoding Rules (BER)__: Binary ASN.1 encoding that appends basic type and length information to each encoded value, which means that decoding a given message does not require knowledge of its original ASN.1 description. Defined in X.690. - __Distinguished Encoding Rules (DER)__: A subset of BER that guarantees canonical representation, which is to say that every pair of structurally equivalent ASN.1 messages can be represented in DER in exactly one way. Must be used when encoding X.509 certificates. Defined in X.690. -- __Object Identifier (OID)__: A structured universally unique identifier, useful for identifying parts of ASN.1 messages. +- __Object Identifier (OID)__: A hierarchical and universally unique identifier, useful for identifying parts of ASN.1 messages. - __Octet__: An 8-bit byte. ### 1.3 Conventions -The words __must__, __must not__, __required__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as follows: __must__ and __required__ denote absolute requirements that must be adhered to by profile adherents; __must not__ denotes an absolute prohibition; __should__, __should not__ and __recommended__ denote recommendations that should be deviated from only if special circumstances make it relevant; and, finally, __may__ and __optional__ denote something being truly optional. +The words __must__, __must not__, __required__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as follows: __must__ and __required__ denote absolute requirements that must be adhered to for a certificate to be considered compliant to a given profile; __must not__ denotes an absolute prohibition; __should__, __should not__ and __recommended__ denote recommendations that should be deviated from only if special circumstances make it relevant; and, finally, __may__ and __optional__ denote something being truly optional. ## 2. Certificate Profiles -There are eight certificate profiles defined in this document, depicted in the diagram further below. -Each diagram box represents a certificate profile. -The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. +There are eight certificate profiles defined in this document, depicted in the following diagram: ``` +---------------+ @@ -94,17 +93,16 @@ The arrows in the diagram are to be read as "issued by", meaning that the every | On-Boarding | | Device | | System | | Operator | +-------------+ +-------------+ +-------------+ +-------------+ ``` +Each diagram box represents a profile. +The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. -We begin by considering the X.509 format itself, after which we first consider the CA certificates (Master, Organization and Local Cloud) and then the end entity certificates (Gate, On-Boarding, Device, System and Operator). +In this section, we begin by considering the X.509 format itself, after which we first consider the CA certificates (Master, Organization and Local Cloud) and then the end entity certificates (Gate, On-Boarding, Device, System and Operator). +The details included in this section are intended to be enough to allow for the correct parameterization of certificates, but are unlikely to be sufficient for implementing software for handling certificate. +If the latter is relevant, please consult RFC 5280, X.509, X.501, X.690 and ASN.1 for all complementary details. ## 2.1 Certificate Format -In this section, we introduce the X.509 certificate format in its ASN.1 syntax. -We describes each of its fields and state how they should be used, if at all, by conforming certificates. -Our descriptions are not, however, rigorous enough to base real-world implementations on only them. -Advanced learners and certificate software implementors should consult the official sources for more details. - -The ASN.1 syntax of the third version of the X.509 certificate is defined in as follows in RFC 5280: +The ASN.1 syntax of the third version of the X.509 certificate format is defined in as follows in RFC 5280: ```asn1 Certificate ::= SEQUENCE { @@ -135,7 +133,7 @@ Each of its fields is described in the following subsections. #### 2.1.1 `version` X.509 version of the certificate. -Must be `v3(2)` for all certificates that utilize certificate extensions, as described in Section 2.1.9. +Only `v3(2)` supports certificate extensions, which _must_ be used by all profiles described in this document. Supporting `v1(0)` and `v2(1)` at all is _optional_. #### 2.1.2 `serialNumber` @@ -158,7 +156,7 @@ This field must contain the same algorithm as the `signatureAlorithm` field in t #### 2.1.4 `issuer` The DN of the issuer of the certificate in question. -More specifically, this field contains an exact copy of the `subject` field of Section 2.1.6 from the certificate of its issuer. +More specifically, this field contains an exact copy of the `subject` field of Section 2.1.6 from the certificate of its issuer, or a copy of the `issuer` field of the same certificate if it is self-signed. #### 2.1.5 `validity` @@ -178,7 +176,7 @@ Time ::= CHOICE { ``` For each of these two dates, the date in question _must_ be encoded as a `UTCTime` if its year is less than or equal to 2049, or as a `GeneralizedTime` if the year is equal to or greater than 2050. -More details about the validity format may be read in Section 4.1.2.5 of RFC 5280. +See Section 4.1.2.5 of RFC 5280 for more details. #### 2.1.6 `subject` @@ -250,7 +248,7 @@ Optional identifiers uniquely associated with the issuer or subject of the certi These fields _must not_ be used. When a certain certificate, or its subject, needs to be identified, the cryptographic hash of the certificate, or its _fingerprint_, _should_ be used. -If desired to identify the subject by its public key, which _may_ be used in multiple certificates, the cryptographic hash of the value bytes of the `subjectPublicKey` field of `subjectPublicKeyInfo` _should_ be used. +If desired to identify the subject by its public key, which _may_ be used in multiple certificates, the cryptographic hash of the `subjectPublicKey` field (excluding the tag, length, and number of unused bits) of `subjectPublicKeyInfo` _should_ be used. See Section 3 for more information about what hashing algorithms should be used for this and other purposes. #### 2.1.9 `extensions` @@ -267,8 +265,7 @@ Extension ::= SEQUENCE { } ``` -RFC 5280 explicitly outlines 17 different X.509 extensions, listed below. -They are categorized for the sake of clarity. +RFC 5280 explicitly outlines 17 different X.509 extensions, listed by category below. | Extension | `extnID` (OID) | Brief Description | |:-----------------------------|:---------------------|:------------------| @@ -304,7 +301,7 @@ The __Authority Key Identifier__ and __Subject Key Identifier__ extensions are u The extensions are defined as follows: ```asn1 --- Required for all but self-signed CA certificates. +-- Required for all but self-signed CA certificates (root CAs). AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, -- Required. authorityCertIssuer [1] GeneralNames OPTIONAL, -- Optional. @@ -383,7 +380,12 @@ GeneralName ::= CHOICE { } ``` +The `SubjectAltName` extension _must_ be used by all end entity certificates and must identify at least one DNS name or IP address. +The extension _must_ be used for CA certificates that handles CSRs directly via network application interfaces. +Use of the `IssuerAltName` is _optional_. + The __Name Constraints__ extension makes it possible for a CA to restrict the set of allowed `subject` and `SubjectAltName` that may be specified in certificates it issues. +The extension _may_ be used. Please refer to RFC 5280 Section 4.2.1.10 for more details. #### 2.1.9.4 CRL Extensions @@ -400,7 +402,7 @@ Its use is _recommended_ for revoking and verifying the validity of end entity c The information extensions allows various types of data sources or services to be associated with the certificate holder. These extensions _should not_ be used. -Eclipse Arrowhead a service-oriented architecture with its own provisions for metadata and service management. +Eclipse Arrowhead a service-oriented architecture with its own provisions for metadata distribution and service management. Those provisions _should_ be used when possible. #### 2.1.9.6 Other Extensions @@ -420,6 +422,7 @@ BasicConstraints ::= SEQUENCE { The extension _must_ be used by all Arrowhead-compliant certificates. The `pathLenConstraint` _must_ be set by all CA certificates. +It _must not_ be set by end entity certificates. ### 2.2 Certificate Hierarchy From 24c4922cdd3bf459481601249c151ac110ad0289 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 19 Aug 2021 10:31:17 +0200 Subject: [PATCH 17/36] Work on proposal.md --- proposal.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposal.md b/proposal.md index acb5c21..3905f24 100644 --- a/proposal.md +++ b/proposal.md @@ -33,7 +33,7 @@ Certificate standard for establishing trust between devices over untrusted compu - __Certificate Authority (CA)__: Entity issuing (signing) other certificates to endorse their validity. - __Certificate Chain__: A chain consisting of an _end entity_ certificate, its _issuer_'s certificate, that _issuer_'s _issuer_'s certificate, and so on up to the _root CA_'s certificate. - __Certificate Revocation List (CRL)__: A list identifying certificates that no longer are to be considered valid even though they are yet to expire. -- __Certificate Signing Request (CSR)__: A description of a desired certificate that can be sent to a CA. +- __Certificate Signing Request (CSR)__: A request for a certificate to be issued by a receiving CA. - __End Entity__: Entity having but not issuing certificates. - __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. - __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. @@ -97,8 +97,8 @@ Each diagram box represents a profile. The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. In this section, we begin by considering the X.509 format itself, after which we first consider the CA certificates (Master, Organization and Local Cloud) and then the end entity certificates (Gate, On-Boarding, Device, System and Operator). -The details included in this section are intended to be enough to allow for the correct parameterization of certificates, but are unlikely to be sufficient for implementing software for handling certificate. -If the latter is relevant, please consult RFC 5280, X.509, X.501, X.690 and ASN.1 for all complementary details. +The details included in this section are intended to be enough to allow for the correct parameterization of certificates, but are unlikely to be sufficient for implementing software for handling them. +If the latter is relevant, please consult RFC 5280, X.509, X.501, X.690 and ASN.1 for complementary details. ## 2.1 Certificate Format @@ -178,6 +178,9 @@ Time ::= CHOICE { For each of these two dates, the date in question _must_ be encoded as a `UTCTime` if its year is less than or equal to 2049, or as a `GeneralizedTime` if the year is equal to or greater than 2050. See Section 4.1.2.5 of RFC 5280 for more details. +The time span denoted by this field _should_ be shorter than the expected lifetime of the entity owning it, if provisions exist for renewing it during its lifetime. +More specific recommendations will be published in other documents of the Eclipse Arrowhead project. + #### 2.1.6 `subject` The DN used to describe the owner of the certificate. @@ -384,7 +387,7 @@ The `SubjectAltName` extension _must_ be used by all end entity certificates and The extension _must_ be used for CA certificates that handles CSRs directly via network application interfaces. Use of the `IssuerAltName` is _optional_. -The __Name Constraints__ extension makes it possible for a CA to restrict the set of allowed `subject` and `SubjectAltName` that may be specified in certificates it issues. +The __Name Constraints__ extension makes it possible for a CA to restrict the set of values allowed for the `subject` and `SubjectAltName` fields in issued certificates. The extension _may_ be used. Please refer to RFC 5280 Section 4.2.1.10 for more details. From b971b28737c543a4466682ff650a6e3f6731caa1 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 19 Aug 2021 10:38:58 +0200 Subject: [PATCH 18/36] Work on proposal.md --- proposal.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposal.md b/proposal.md index 3905f24..2651e65 100644 --- a/proposal.md +++ b/proposal.md @@ -96,9 +96,9 @@ There are eight certificate profiles defined in this document, depicted in the f Each diagram box represents a profile. The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. -In this section, we begin by considering the X.509 format itself, after which we first consider the CA certificates (Master, Organization and Local Cloud) and then the end entity certificates (Gate, On-Boarding, Device, System and Operator). +In this section, we begin by considering the X.509 format itself, after which we outline the Master, Gate, Organization, Local Cloud, On-Boarding, Device, System and Operator profiles. The details included in this section are intended to be enough to allow for the correct parameterization of certificates, but are unlikely to be sufficient for implementing software for handling them. -If the latter is relevant, please consult RFC 5280, X.509, X.501, X.690 and ASN.1 for complementary details. +If the latter is relevant, please refer to RFC 5280, X.509, X.501, X.690 and ASN.1. ## 2.1 Certificate Format @@ -346,9 +346,14 @@ KeyPurposeId ::= OBJECT IDENTIFIER The `KeyUsage` extension is a set of bit flags used to indicate various ways in which a certificate _may_ be used. Please refer to RFC 5280 Section 4.2.1.3 for descriptions of each bit flag. +The extension _must_ be used in all certificates. +How to set it is outlined in the section specific to each particular certificate profile. The `ExtKeyUsageSyntax` extension has the same purpose, but is open-ended in the sense that it allows for any OID to be used as an indication of what a certain certificate _may_ be used for. RFC 5280 lists six such identifiers, out of which two has particular bearing on this document, namely the `serverAuth` (OID `1.3.6.1.5.5.7.3.1`) and `clientAuth` (OID `1.3.6.1.5.5.7.3.2`) identifiers, which indicate that the certificate holder should be allowed to act as a World Wide Web TLS server and client, respectively. +The extension _must_ be used in all end entity certificates, as well in the certificates of the CAs that handle CSRs directly via network application interfaces. +The `serverAuth` and `clientAuth` identifiers _must_ be included. +Other identifiers _may_ be used. #### 2.1.9.2 Policy Extensions @@ -427,8 +432,6 @@ The extension _must_ be used by all Arrowhead-compliant certificates. The `pathLenConstraint` _must_ be set by all CA certificates. It _must not_ be set by end entity certificates. -### 2.2 Certificate Hierarchy - ### 2.3 CA Certificates #### 2.3.1 Common Fields From 05ab8fe2d0311a5b9e9c5cad76e5adb739187e98 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 19 Aug 2021 10:52:27 +0200 Subject: [PATCH 19/36] Work on proposal.md --- proposal.md | 219 ++++++++-------------------------------------------- 1 file changed, 32 insertions(+), 187 deletions(-) diff --git a/proposal.md b/proposal.md index 2651e65..95c8a9a 100644 --- a/proposal.md +++ b/proposal.md @@ -231,6 +231,10 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. | Serial Number | `SN` | `2.5.4.5` | State or Province Name | `ST` | `2.5.4.8` +All end entity certificates _must_ contain a `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters, which is to say that they match the regular expression `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. +While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. +The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). + #### 2.1.7 `subjectPublicKeyInfo` The public key of the subject, as well as the identity of the algorithm associated with it. @@ -432,223 +436,64 @@ The extension _must_ be used by all Arrowhead-compliant certificates. The `pathLenConstraint` _must_ be set by all CA certificates. It _must not_ be set by end entity certificates. -### 2.3 CA Certificates +### 2.2 Master Profile -#### 2.3.1 Common Fields +#### 2.2.1 `issuer` -#### 2.3.1.1 `validity` +_May_ be self-signed or issued by an RFC 5280-compliant CA. -TODO: Write something about sensible validity periods for certs. - -#### 2.3.1.2 `subject` +#### 2.2.2 `subject` | Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. -| DN Qualifier (DN) | `2.5.4.46` | Yes | _Profile identifier_ specific to each certificate profile. +| DN Qualifier (DN) | `2.5.4.46` | Yes | `master`. | Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. -#### 2.3.1.3 `extensions` +#### 2.2.3 `extensions` | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Authority Key Identifier | `2.5.29.35` | No | See Section 2.1.9.1. +| Authority Key Identifier | `2.5.29.35` | No | Required only if not self-signed. See Section 2.1.9.1. | Subject Key Identifier | `2.5.29.14` | No | See Section 2.1.9.1. -| Basic Constraints | `2.5.29.19` | Yes | See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. - -### 2.3.2 Profiles - -#### 2.3.2.1 Master - -Issued by any suitable RFC 5280 certificate, or none at all (self-signed). - -Validity? - -`subject` - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| DN Qualifier (DN) | `2.5.4.46` | Yes | `master` | - -`extensions` - -| Extension | OID | Critical | Value | -|:-----------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2` | - -### 2.3.2.2 Organization - -Issued by a _Master_ certificate. - -Validity - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | `organization` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:-----------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1` | -| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | - -### 3.4 Local Cloud - -#### Issuer - -An _Organization_ certificate. - -#### Subject - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| DN Qualifier (DN) | `2.5.4.46` | Yes | `localcloud` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:-----------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0` | -| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | - +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2`. See Section 2.1.9.6. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. If responding to CSRs via network application interface, then `digitalSignature(0)` and `keyEncipherment(2)` _must_ also be set. See Section 2.1.9.1. +| ExtendedKeyUsage | `2.5.29.37` | No | If responding to CSRs via network application interface, then `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. | -### 2.3 End Entity Certificates +### 2.3 Gate Profile -#### 2.2.1 `validity` +#### 2.3.1 `issuer` -TODO: Write something about sensible validity periods for certs. +_Must_ be issued by a _Master_ certificate. -#### 2.2.2 `subject` +#### 2.3.2 `subject` | Attribute Type | OID | Required | Value | |:------------------|:-----------|:---------|:------| | Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | _Identifier_ specified for each profile. | +| DN Qualifier (DN) | `2.5.4.46` | Yes | `gate`. | | Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | -__Entity naming__. -Some end entity certificates, as mentioned in their respective profile sections, must contain a subject Common Name (CN) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. -While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. -The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). -Concretely, when a subject CN in this chapter is required to be a _valid DNS label_, it is to be understood that it matches the following regular expression: `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. -This means that full domain names are _not_ allowed as subject CN, such as `my-device.company.arrowhead.eu`. -In the case of that example, it should rather have been `my-device`. -Full domain names are specified as subject alternative names where relevant. +#### 2.3.3 `extensions` -#### 2.2.3 `extensions` - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | - -### 2.3 Transfer Certificates - -## 3. Arrowhead X.509 Profiles - - -### 3.5 On-Boarding - -#### Issuer - -A _Local Cloud_ certificate. - -#### Subject - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| DN Qualifier (DN) | `2.5.4.46` | Yes | `onboarding` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | - -### 3.6 Device - -#### Issuer - -A _Local Cloud_ certificate. - -#### Subject - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| DN Qualifier (DN) | `2.5.4.46` | Yes | `device` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | - -### 3.7 System - -#### Issuer - -A _Local Cloud_ certificate. - -#### Subject - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | `system` | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the device owning the certificate. | - -### 3.8 Operator - -#### Issuer - -A _Local Cloud_ certificate. - -#### Subject - -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| DN Qualifier (DN) | `2.5.4.46` | Yes | `operator` | -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of operator. | - -#### Extensions - -| Extension | OID | Critical | Value | -|:------------------------|:------------|:---------|:------| -| KeyUsage | `2.5.29.15` | Yes | `digitalSignature(0), keyEncipherment(2)` | -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth(1.3.6.1.5.5.7.3.1), clientAuth(1.3.6.1.5.5.7.3.2)` | -| SubjectAlternativeNames | `2.5.29.17` | Yes | IPv4, IPv6 and DNS addresses/names associated with the devices from which the operator administers its local cloud. | +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.6. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.1. +| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. | -### 3.9 Manufacturer +### 2.4 Organization Profile -#### Issuer +### 2.5 Local Cloud Profile -Any or none at all. +### 2.6 On-Boarding Profile -### 3.10 Transfer +### 2.7 Device Profile -#### Issuer +### 2.8 System Profile -A _Manufacturer_ certificate. +### 2.9 Operator Profile ## 3. Algorithms, Key Lengths and Other Security Details From 932dc9c3429d259a16d7b0234ed3cf96ab92826d Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 20 Aug 2021 14:02:14 +0200 Subject: [PATCH 20/36] Work on proposal.md --- proposal.md | 59 ++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 43 insertions(+), 16 deletions(-) diff --git a/proposal.md b/proposal.md index 95c8a9a..2ac1a92 100644 --- a/proposal.md +++ b/proposal.md @@ -97,6 +97,7 @@ Each diagram box represents a profile. The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. In this section, we begin by considering the X.509 format itself, after which we outline the Master, Gate, Organization, Local Cloud, On-Boarding, Device, System and Operator profiles. +Each profile is described in terms of its (a) purpose, (b) issuer, (c) subject name and (d) extensions. The details included in this section are intended to be enough to allow for the correct parameterization of certificates, but are unlikely to be sufficient for implementing software for handling them. If the latter is relevant, please refer to RFC 5280, X.509, X.501, X.690 and ASN.1. @@ -323,10 +324,11 @@ KeyIdentifier ::= OCTET STRING RFC 5280 _requires_ that `AuthorityKeyIdentifier` extension is included in all CA certificates except for self-signed such. The `keyIdentifier` of the `AuthorityKeyIdentifier` extension of a given certificate _must_ match the `SubjectKeyIdentifier` of its issuer's certificate, or _may_ be omitted if the certificate is self-signed. -Use of the `authorityCertIssuer` and `authorityCertSerialNumber` fields of `AuthorityKeyIdentifier` is optional. +Use of the `authorityCertIssuer` and `authorityCertSerialNumber` fields of `AuthorityKeyIdentifier` is _not recommended_. If a self-signed certificate leaves the `authorityCertIssuer` and `authorityCertSerialNumber` fields unspecified, it may omit the `AuthorityKeyIdentifier` extension entirely. RFC 5280 further _requires_ that all but end entity certificates use the `SubjectKeyIdentifier` extension. Its value _should_ be the the cryptographic hash of the `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field. +The extensions _must not_ be marked as critical. The __Key Usage__ and __Extended Key Usage__ extensions are defined as follows: @@ -350,13 +352,14 @@ KeyPurposeId ::= OBJECT IDENTIFIER The `KeyUsage` extension is a set of bit flags used to indicate various ways in which a certificate _may_ be used. Please refer to RFC 5280 Section 4.2.1.3 for descriptions of each bit flag. -The extension _must_ be used in all certificates. +The extension _must_ be used in all certificates and _must_ be marked as critical. How to set it is outlined in the section specific to each particular certificate profile. The `ExtKeyUsageSyntax` extension has the same purpose, but is open-ended in the sense that it allows for any OID to be used as an indication of what a certain certificate _may_ be used for. RFC 5280 lists six such identifiers, out of which two has particular bearing on this document, namely the `serverAuth` (OID `1.3.6.1.5.5.7.3.1`) and `clientAuth` (OID `1.3.6.1.5.5.7.3.2`) identifiers, which indicate that the certificate holder should be allowed to act as a World Wide Web TLS server and client, respectively. The extension _must_ be used in all end entity certificates, as well in the certificates of the CAs that handle CSRs directly via network application interfaces. The `serverAuth` and `clientAuth` identifiers _must_ be included. +The extension _should not_ be marked as _critical_. Other identifiers _may_ be used. #### 2.1.9.2 Policy Extensions @@ -392,12 +395,14 @@ GeneralName ::= CHOICE { } ``` -The `SubjectAltName` extension _must_ be used by all end entity certificates and must identify at least one DNS name or IP address. -The extension _must_ be used for CA certificates that handles CSRs directly via network application interfaces. +The `SubjectAltName` extension _must_ be used by all end entity certificates and _must_ identify at least one DNS name or IP address. +The extension _must_ also be used for CA certificates that handles CSRs directly via network application interfaces. Use of the `IssuerAltName` is _optional_. +Both extensions _should_ be marked as non-critical. The __Name Constraints__ extension makes it possible for a CA to restrict the set of values allowed for the `subject` and `SubjectAltName` fields in issued certificates. The extension _may_ be used. +It _must_ be marked as critical if used. Please refer to RFC 5280 Section 4.2.1.10 for more details. #### 2.1.9.4 CRL Extensions @@ -421,6 +426,7 @@ Those provisions _should_ be used when possible. The __Subject Directory Attributes__ allows for arbitrary identification attributes, such as nationality, to be associated with the `subject` of a certificate. It _may_ be used. +It _must_ be marked as non-critical if used. The __Basic Constraints__ extension allows for it to be denoted whether or not a given certificate belongs to a CA, as well as how many intermediary CAs may exist below it in any given certificate chain. The extension is defined as follows: @@ -432,33 +438,54 @@ BasicConstraints ::= SEQUENCE { } ``` -The extension _must_ be used by all Arrowhead-compliant certificates. -The `pathLenConstraint` _must_ be set by all CA certificates. -It _must not_ be set by end entity certificates. +The extension _must_ be used and marked critical by all Arrowhead-compliant certificates. +The `pathLenConstraint` _must_ be set by all CA certificates, but _must not_ be set by end entity certificates. ### 2.2 Master Profile +A _Master_ certificate exists to establish trust between organizations that may want to interconnect their Arrowhead systems. +It does this by issuing _Organization_ and _Gate_ certificates. +The former kind of certificate enables organizations to set up their own certificate hierarchies while sharing a common CA with all other organizations. +The latter kind enables all those organizations to trust a special kind of broker system, which facilitates negotiating connections between organizations. + +The Eclipse Arrowhead project _should_ maintain an authoritative Master certificate that _may_ be used for non-private Arrowhead installations. +Other entities _may_ setup and maintain their own Master certificates as needed. + #### 2.2.1 `issuer` _May_ be self-signed or issued by an RFC 5280-compliant CA. +__Security notice__. +In the case of a Master being issued by a widely trusted World Wide Web CA, entities with the Master in their certificate chains could be made able to serve HTTP(S) traffic to regular web browsers without any additional certificate distribution. +It could also make it possible for improperly configured systems to establish secure connections with unauthorized systems. +Having CAs above a Master provides for new opportunities and new risks at the same time, for which reason it may or may not be desirable. + #### 2.2.2 `subject` -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. -| DN Qualifier (DN) | `2.5.4.46` | Yes | `master`. -| Common Name (CN) | `2.5.4.3` | Yes | Human-readable name of certificate. +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `master`. +| Common Name (CN) | `2.5.4.3` | Human-readable name of certificate, such as `LTU Master RSA 2021`. #### 2.2.3 `extensions` +The following extensions _must_ be used and configured as described: + | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Authority Key Identifier | `2.5.29.35` | No | Required only if not self-signed. See Section 2.1.9.1. -| Subject Key Identifier | `2.5.29.14` | No | See Section 2.1.9.1. +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. Omit field if self-signed. See Section 2.1.9.1. +| Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. | Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2`. See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. If responding to CSRs via network application interface, then `digitalSignature(0)` and `keyEncipherment(2)` _must_ also be set. See Section 2.1.9.1. -| ExtendedKeyUsage | `2.5.29.37` | No | If responding to CSRs via network application interface, then `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. | +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. + +If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. +| ExtendedKeyUsage | `2.5.29.37` | No | Both`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. ### 2.3 Gate Profile From 6b596c1be21a886016cd8573f7e8bf80738094e8 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 20 Aug 2021 14:39:20 +0200 Subject: [PATCH 21/36] Work on proposal.md --- proposal.md | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/proposal.md b/proposal.md index 2ac1a92..a9683ac 100644 --- a/proposal.md +++ b/proposal.md @@ -232,9 +232,13 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. | Serial Number | `SN` | `2.5.4.5` | State or Province Name | `ST` | `2.5.4.8` -All end entity certificates _must_ contain a `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters, which is to say that they match the regular expression `^(?![0-9]+$)(?!.*-$)(?!-)[a-zA-Z0-9-]{1,62}$`. -While up to 62 characters are allowed, however, we recommend that names be kept under 20 characters when possible to avoid exceeding the 255 character limit of DNS when including them in domain names. -The reason for the DNS adherence is to guarantee compatibility with DNS-SD and other naming schemas related to Arrowhead (https://ieeexplore.ieee.org/document/8972250). +Every certificate _must_ contain exactly one `subject` _Distinguished Name Qualifier_ (`DN`) that identifies the profile it adheres to. +The actual identifiers are stated in Sections 2.2 to 2.10. + +In addition, all end entity and Local Cloud certificates _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +Note that DNS labels _must not_ contain dots, or any other character than the alphanumeric and dash. +While names _may_ use 62 characters, we _recommend_ that names be kept at 20 characters or less. +The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA that have the same profile. #### 2.1.7 `subjectPublicKeyInfo` @@ -356,11 +360,11 @@ The extension _must_ be used in all certificates and _must_ be marked as critica How to set it is outlined in the section specific to each particular certificate profile. The `ExtKeyUsageSyntax` extension has the same purpose, but is open-ended in the sense that it allows for any OID to be used as an indication of what a certain certificate _may_ be used for. -RFC 5280 lists six such identifiers, out of which two has particular bearing on this document, namely the `serverAuth` (OID `1.3.6.1.5.5.7.3.1`) and `clientAuth` (OID `1.3.6.1.5.5.7.3.2`) identifiers, which indicate that the certificate holder should be allowed to act as a World Wide Web TLS server and client, respectively. +RFC 5280 lists six such purpose identifiers, out of which two has particular bearing on this document, namely the `serverAuth` (OID `1.3.6.1.5.5.7.3.1`) and `clientAuth` (OID `1.3.6.1.5.5.7.3.2`) identifiers, which indicate that the certificate holder must be able to respond to TLS server and client authorization requests, respectively. The extension _must_ be used in all end entity certificates, as well in the certificates of the CAs that handle CSRs directly via network application interfaces. The `serverAuth` and `clientAuth` identifiers _must_ be included. The extension _should not_ be marked as _critical_. -Other identifiers _may_ be used. +Other purpose identifiers _may_ be used. #### 2.1.9.2 Policy Extensions @@ -412,15 +416,15 @@ These extensions _should not_ be used to facilitate the revocation of end entity They _may_ be used for revoking CA certificates. Eclipse Arrowhead comes with its own certificate revocation procedure via its _Certificate Authority_ system. -Its use is _recommended_ for revoking and verifying the validity of end entity certificates. +Its use is _recommended_ for revoking and verifying the validity of On-Boarding, Device, System and Operator certificates. #### 2.1.9.5 Information Extension The information extensions allows various types of data sources or services to be associated with the certificate holder. These extensions _should not_ be used. -Eclipse Arrowhead a service-oriented architecture with its own provisions for metadata distribution and service management. -Those provisions _should_ be used when possible. +Eclipse Arrowhead has its own provisions for metadata distribution and service management, via the _Service Registry_ system, _Gatekeeper_ system, and other. +Those provisions _should_ be used. #### 2.1.9.6 Other Extensions @@ -445,7 +449,7 @@ The `pathLenConstraint` _must_ be set by all CA certificates, but _must not_ be A _Master_ certificate exists to establish trust between organizations that may want to interconnect their Arrowhead systems. It does this by issuing _Organization_ and _Gate_ certificates. -The former kind of certificate enables organizations to set up their own certificate hierarchies while sharing a common CA with all other organizations. +The former enables organizations to set up their own certificate hierarchies while sharing a common CA with all other organizations. The latter kind enables all those organizations to trust a special kind of broker system, which facilitates negotiating connections between organizations. The Eclipse Arrowhead project _should_ maintain an authoritative Master certificate that _may_ be used for non-private Arrowhead installations. @@ -467,7 +471,7 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| | DN Qualifier (DN) | `2.5.4.46` | `master`. -| Common Name (CN) | `2.5.4.3` | Human-readable name of certificate, such as `LTU Master RSA 2021`. +| Common Name (CN) | `2.5.4.3` | Human-readable name of certificate, such as `LTU RSA 2021`. #### 2.2.3 `extensions` @@ -485,30 +489,38 @@ If the certificate will be used to automatically respond to CSRs via a network a | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. -| ExtendedKeyUsage | `2.5.29.37` | No | Both`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. ### 2.3 Gate Profile +A _Gate_ certificate is associated with some form of message broker or bus that exists to guarantee delivery of messages between the local clouds of the same or distinct organizations. +Its existence means that such messages can sent over a secure transport. + #### 2.3.1 `issuer` -_Must_ be issued by a _Master_ certificate. +_Must_ be issued by a Master certificate. #### 2.3.2 `subject` -| Attribute Type | OID | Required | Value | -|:------------------|:-----------|:---------|:------| -| Organization (O) | `2.5.4.6` | No | Human-readable name of owning organization. | -| DN Qualifier (DN) | `2.5.4.46` | Yes | `gate`. | -| Common Name (CN) | `2.5.4.3` | Yes | A valid DNS name label of 1 to 62 characters. | +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `gate`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `mqtt-04`. See Section 2.1.6. #### 2.3.3 `extensions` +The following extensions _must_ be used and configured as described: + | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Authority Key Identifier | `2.5.29.35` | No | See Section 2.1.9.1. +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. | Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.6. | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.1. -| ExtendedKeyUsage | `2.5.29.37` | No | `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. | +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name through which the system can be reached. See Section 2.1.9.3. ### 2.4 Organization Profile From a8a0e2028407e3dea539580b4c999bb575967876 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 20 Aug 2021 16:23:50 +0200 Subject: [PATCH 22/36] Work on proposal.md --- proposal.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposal.md b/proposal.md index a9683ac..9231d9d 100644 --- a/proposal.md +++ b/proposal.md @@ -449,7 +449,7 @@ The `pathLenConstraint` _must_ be set by all CA certificates, but _must not_ be A _Master_ certificate exists to establish trust between organizations that may want to interconnect their Arrowhead systems. It does this by issuing _Organization_ and _Gate_ certificates. -The former enables organizations to set up their own certificate hierarchies while sharing a common CA with all other organizations. +The former enables organizations to set up their own certificate hierarchies while sharing a common CA with other organizations. The latter kind enables all those organizations to trust a special kind of broker system, which facilitates negotiating connections between organizations. The Eclipse Arrowhead project _should_ maintain an authoritative Master certificate that _may_ be used for non-private Arrowhead installations. @@ -494,7 +494,7 @@ If the certificate will be used to automatically respond to CSRs via a network a ### 2.3 Gate Profile -A _Gate_ certificate is associated with some form of message broker or bus that exists to guarantee delivery of messages between the local clouds of the same or distinct organizations. +A _Gate_ certificate is associated with a message broker or bus that exists to guarantee delivery of messages between the local clouds of distinct organizations. Its existence means that such messages can sent over a secure transport. #### 2.3.1 `issuer` @@ -536,6 +536,8 @@ The following extensions _must_ be used and configured as described: ## 3. Algorithms, Key Lengths and Other Security Details +https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014 + - Use fingerprints to identify certificate owners, not subject names. ## 4. Certificate Creation and Distribution From c6e929106464978e46b6e9847b3d3297c450576b Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 23 Aug 2021 10:27:12 +0200 Subject: [PATCH 23/36] Work on proposal.md; chapter 3 --- proposal.md | 43 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/proposal.md b/proposal.md index 9231d9d..e9d432f 100644 --- a/proposal.md +++ b/proposal.md @@ -536,9 +536,46 @@ The following extensions _must_ be used and configured as described: ## 3. Algorithms, Key Lengths and Other Security Details -https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014 - -- Use fingerprints to identify certificate owners, not subject names. +Every X.509 certificate must be configured to use a particular _signature scheme_, as mentioned in Section 2.1.3, which typically consists of a signature algorithm and a secure hash algorithm. +In addition, if a given certificate is used with a protocol such as TLS, that signature scheme will be part of a _cipher suite_, which also likely will include a key exchange algorithm and a block or stream cipher. +Choosing these schemes poorly can lead to severe security vulnerabilities. + +Every organization that depends critically on cryptographic algorithms for any of their operations _should_ make it a priority to ensure they have access to their own experts that can help them choose cryptographic primitives and manage their keys and other cryptographic assets. +That being said, there are several credible organizations that publish reports regarding what signature and cipher suites to use, such as NIST, ENSIA and IETF. +The latter of the three published RFC 7525 (https://datatracker.ietf.org/doc/html/rfc7525) in May 2015, which recommends that the following four cipher suites be used with TLS: + +1. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + - __Key Exchange__: Diffie-Hellman Ephemeral (DHE) + - __Authentication__: Rivest Shamir Adleman (RSA) + - __Encryption__: Advanced Encryption Standard with 128-bit key in Galois/Counter mode (AES 128 GCM) + - __Hash__: Secure Hash Algorithm 256 (SHA256) +2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + - __Key Exchange__: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) + - __Authentication__: Rivest Shamir Adleman (RSA) + - __Encryption__: Advanced Encryption Standard with 128-bit key in Galois/Counter mode (AES 128 GCM) + - __Hash__: Secure Hash Algorithm 256 (SHA256) +3. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 + - __Key Exchange__: Diffie-Hellman Ephemeral (DHE) + - __Authentication__: Rivest Shamir Adleman (RSA) + - __Encryption__: Advanced Encryption Standard with 256-bit key in Galois/Counter mode (AES 256 GCM) + - __Hash__: Secure Hash Algorithm 384 (SHA384) +4. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + - __Key Exchange__: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) + - __Authentication__: Rivest Shamir Adleman (RSA) + - __Encryption__: Advanced Encryption Standard with 256-bit key in Galois/Counter mode (AES 256 GCM) + - __Hash__: Secure Hash Algorithm 384 (SHA384) + +RSA keys _should not_ have lengths of less than 2048 bits. +In a 2018 report by the Ecrypt project (https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf), an effective cryptographic strength of 128 bits is recommended for new deployments in the following years (see also https://doi.org/10.6028/NIST.SP.800-57pt1r5 and https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014). +According to their own estimates, that requires that RSA be used with a key length of 3072-bits. + +If following the RFC 7525 recommendation, RSA with SHA _should_ be used as signature algorithm in any created X.509 certificates, where 2048-bit or 3072-bit keys be used with RSA and either SHA256 or SHA384 be used. + +The above recommendations are _general_, in the sense that no particular assumptions are made about the setting in which the device employing the signature or cipher suite is located. +We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. +The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. + +Note that all TLS versions prior to 1.2 are deprecated, as per RFC 8996. ## 4. Certificate Creation and Distribution From 179fe2ddfa3211a5b622e7f2b2bbfd243917ddef Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 23 Aug 2021 11:09:37 +0200 Subject: [PATCH 24/36] Work on proposal.md; update chapter 3 --- proposal.md | 56 ++++++++++++++--------------------------------------- 1 file changed, 15 insertions(+), 41 deletions(-) diff --git a/proposal.md b/proposal.md index e9d432f..669b8a7 100644 --- a/proposal.md +++ b/proposal.md @@ -536,47 +536,26 @@ The following extensions _must_ be used and configured as described: ## 3. Algorithms, Key Lengths and Other Security Details -Every X.509 certificate must be configured to use a particular _signature scheme_, as mentioned in Section 2.1.3, which typically consists of a signature algorithm and a secure hash algorithm. -In addition, if a given certificate is used with a protocol such as TLS, that signature scheme will be part of a _cipher suite_, which also likely will include a key exchange algorithm and a block or stream cipher. -Choosing these schemes poorly can lead to severe security vulnerabilities. - -Every organization that depends critically on cryptographic algorithms for any of their operations _should_ make it a priority to ensure they have access to their own experts that can help them choose cryptographic primitives and manage their keys and other cryptographic assets. -That being said, there are several credible organizations that publish reports regarding what signature and cipher suites to use, such as NIST, ENSIA and IETF. -The latter of the three published RFC 7525 (https://datatracker.ietf.org/doc/html/rfc7525) in May 2015, which recommends that the following four cipher suites be used with TLS: - -1. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - - __Key Exchange__: Diffie-Hellman Ephemeral (DHE) - - __Authentication__: Rivest Shamir Adleman (RSA) - - __Encryption__: Advanced Encryption Standard with 128-bit key in Galois/Counter mode (AES 128 GCM) - - __Hash__: Secure Hash Algorithm 256 (SHA256) -2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - - __Key Exchange__: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) - - __Authentication__: Rivest Shamir Adleman (RSA) - - __Encryption__: Advanced Encryption Standard with 128-bit key in Galois/Counter mode (AES 128 GCM) - - __Hash__: Secure Hash Algorithm 256 (SHA256) -3. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - - __Key Exchange__: Diffie-Hellman Ephemeral (DHE) - - __Authentication__: Rivest Shamir Adleman (RSA) - - __Encryption__: Advanced Encryption Standard with 256-bit key in Galois/Counter mode (AES 256 GCM) - - __Hash__: Secure Hash Algorithm 384 (SHA384) -4. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - - __Key Exchange__: Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) - - __Authentication__: Rivest Shamir Adleman (RSA) - - __Encryption__: Advanced Encryption Standard with 256-bit key in Galois/Counter mode (AES 256 GCM) - - __Hash__: Secure Hash Algorithm 384 (SHA384) - -RSA keys _should not_ have lengths of less than 2048 bits. -In a 2018 report by the Ecrypt project (https://www.ecrypt.eu.org/csa/documents/D5.4-FinalAlgKeySizeProt.pdf), an effective cryptographic strength of 128 bits is recommended for new deployments in the following years (see also https://doi.org/10.6028/NIST.SP.800-57pt1r5 and https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014). -According to their own estimates, that requires that RSA be used with a key length of 3072-bits. - -If following the RFC 7525 recommendation, RSA with SHA _should_ be used as signature algorithm in any created X.509 certificates, where 2048-bit or 3072-bit keys be used with RSA and either SHA256 or SHA384 be used. +Choosing a signature scheme for a certificate poorly can lead to severe security vulnerabilities. +We _recommend_ that relevant recommendations of credible information security institutes, such as NIST, ENSIA or IETF, be consulted for making choices about algorithms, key lengths and other relevant security details. + +Given that no relevant breakthroughs are made or expected in quantum computing, you _may_ chose to follow RFC 7525, which recommends the following four TLS _cipher suites_: + +| Key Exchange | Authentication | Encryption | Hash | +|:-------------|:-------------------|:------------|:-------| +| DHE | RSA (2048 or 3072) | AES 128 GCM | SHA256 | +| ECDHE | RSA (2048 or 3072) | AES 128 GCM | SHA256 | +| DHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | +| ECDHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | + +Note that all TLS versions prior to 1.2 are deprecated, as per RFC 8996. +A cipher suite is a collection of cryptographic algorithm used to establish secure connections over untrusted transports. +The _Authentication_ and _Hash_ algorithms of a cipher suite constitute what is referred to as a _signature scheme_, which must be specified in and used with every created X.509 certificate, as mentioned in Section 2.1.3. The above recommendations are _general_, in the sense that no particular assumptions are made about the setting in which the device employing the signature or cipher suite is located. We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. -Note that all TLS versions prior to 1.2 are deprecated, as per RFC 8996. - ## 4. Certificate Creation and Distribution ## 5. Authentication and Authorization @@ -598,8 +577,3 @@ However, as mobility at a scale that makes this setup a problem is currently dee It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. ## References - -| Extension | OID | Critical | Value | -|:-----------------|:------------|:---------|:------| -| BasicConstraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1` | -| KeyUsage | `2.5.29.15` | Yes | `keyCertSign(5), cRLSign(6)` | \ No newline at end of file From c83db1f59d09e2c035eccda4fb34bb0866d41c32 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 23 Aug 2021 11:14:39 +0200 Subject: [PATCH 25/36] Work on proposal.md; all certificates must have DNS label CN --- proposal.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposal.md b/proposal.md index 669b8a7..70b8ddd 100644 --- a/proposal.md +++ b/proposal.md @@ -235,10 +235,10 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. Every certificate _must_ contain exactly one `subject` _Distinguished Name Qualifier_ (`DN`) that identifies the profile it adheres to. The actual identifiers are stated in Sections 2.2 to 2.10. -In addition, all end entity and Local Cloud certificates _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +In addition, each certificates _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. Note that DNS labels _must not_ contain dots, or any other character than the alphanumeric and dash. While names _may_ use 62 characters, we _recommend_ that names be kept at 20 characters or less. -The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA that have the same profile. +The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA with same Distinguished Name Qualifier (`DN`). #### 2.1.7 `subjectPublicKeyInfo` @@ -471,7 +471,7 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| | DN Qualifier (DN) | `2.5.4.46` | `master`. -| Common Name (CN) | `2.5.4.3` | Human-readable name of certificate, such as `LTU RSA 2021`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `ltu-rsa-2021`. #### 2.2.3 `extensions` From 2e4408406c988f3e6068db92fb83a6913c24a1d8 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 23 Aug 2021 11:24:01 +0200 Subject: [PATCH 26/36] Work on proposal.md; add sections 2.4, 2.5 --- proposal.md | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 1 deletion(-) diff --git a/proposal.md b/proposal.md index 70b8ddd..929a7ce 100644 --- a/proposal.md +++ b/proposal.md @@ -418,7 +418,7 @@ They _may_ be used for revoking CA certificates. Eclipse Arrowhead comes with its own certificate revocation procedure via its _Certificate Authority_ system. Its use is _recommended_ for revoking and verifying the validity of On-Boarding, Device, System and Operator certificates. -#### 2.1.9.5 Information Extension +#### 2.1.9.5 Information Extensions The information extensions allows various types of data sources or services to be associated with the certificate holder. These extensions _should not_ be used. @@ -524,8 +524,76 @@ The following extensions _must_ be used and configured as described: ### 2.4 Organization Profile +An _Organization_ certificate is maintained by a single organization, allowing it to manage the certificates of its own local clouds. + +#### 2.4.1 `issuer` + +_Must_ be issued by a Master certificate. + +#### 2.4.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `organization`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `company-rsa-2021`. + +#### 2.4.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1`. See Section 2.1.9.6. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. + +If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. + ### 2.5 Local Cloud Profile +An _Local Cloud_ certificate is maintained by a single local cloud, enabling it to issue end entity certificates for on-boarding and on-boarded devices, as well as for systems and operators. + +#### 2.4.1 `issuer` + +_Must_ be issued by an Organization certificate. + +#### 2.4.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `localcloud`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `pumping-station-04`. + +#### 2.4.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0`. See Section 2.1.9.6. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. + +If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. + ### 2.6 On-Boarding Profile ### 2.7 Device Profile From 2bf719d13da85352a4e6e3af568c9a368725905e Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Mon, 23 Aug 2021 17:09:57 +0200 Subject: [PATCH 27/36] Add profile-hierarchy.svg --- profile-hierarchy.svg | 2 ++ proposal.md | 26 ++------------------------ 2 files changed, 4 insertions(+), 24 deletions(-) create mode 100644 profile-hierarchy.svg diff --git a/profile-hierarchy.svg b/profile-hierarchy.svg new file mode 100644 index 0000000..52ac59d --- /dev/null +++ b/profile-hierarchy.svg @@ -0,0 +1,2 @@ + +MasterOrganizationLocal CloudGateDeviceOn-BoardingSystemOperatorIssuerEnd Entity diff --git a/proposal.md b/proposal.md index 929a7ce..b0125c0 100644 --- a/proposal.md +++ b/proposal.md @@ -69,30 +69,8 @@ The words __must__, __must not__, __required__, __should__, __should not__, __re There are eight certificate profiles defined in this document, depicted in the following diagram: -``` - +---------------+ - | Master | - +---------------+ - A - | - +--------------------+ - | | - +-------+-------+ +-------+-------+ - | Organization | | Gate | - +---------------+ +---------------+ - A - | - +-------+-------+ - | Local Cloud | - +---------------+ - A - | - +-----------------+--------+--------+-----------------+ - | | | | -+------+------+ +------+------+ +------+------+ +------+------+ -| On-Boarding | | Device | | System | | Operator | -+-------------+ +-------------+ +-------------+ +-------------+ -``` +![Hierarchy of X.509 Profiles](profile-hierarchy.svg) + Each diagram box represents a profile. The arrows in the diagram are to be read as "issued by", meaning that the every certificate adhering to the profile from which the arrow extends must be issued (signed) by a certificate with the profile pointed to. From 0f2cd7d449e468accbe321478087e8305960499c Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Tue, 24 Aug 2021 10:40:58 +0200 Subject: [PATCH 28/36] Work on proposal.md --- proposal.md | 96 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 55 insertions(+), 41 deletions(-) diff --git a/proposal.md b/proposal.md index b0125c0..a0e4f00 100644 --- a/proposal.md +++ b/proposal.md @@ -61,6 +61,22 @@ The standard is used to describe the structure of X.509 certificates, which _mus - __Object Identifier (OID)__: A hierarchical and universally unique identifier, useful for identifying parts of ASN.1 messages. - __Octet__: An 8-bit byte. +#### 1.2.5 TLS + +_Transport Layer Security_ (TLS), an IETF (Internet Engineering Task-Force) standard for establishing secure connection over untrusted transports. +Used in tandem with X.509 to establish that the identities of any connecting parties can be mutually authenticated. + +- __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a counter-party. +- __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. +- __Encryption Algorithm__: A symmetric encryption algorithm, typically used to make data opaque in transit between a sender and a recipient. Also referred to as _stream_ or _block_ cipher, depending on its mode of operation. +- __Key Exchange Algorithm__: An algorithm used by parties for exchanging _public keys_ as part of preparing for secure communication. +- __Hash Algorithm__: A function that produces an arbitrary fixed-size output for any given arbitrarily sized input. The same input always produces the same output. Used to reduce the size of public key signatures. +- __Party__: Either end of a two-way communication. +- __Public key__: The public component of a public/private key pair. Knowledge of the public key allows for messages to be encrypted such that only the possessor of the private key can decrypt them, and vice versa. Used to produce _signatures_ and to _share secrets_. +- __Shared Secret__: The input to an _encryption algorithm_ that has been shared between two parties such that no other party can see it. +- __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Any party with the corresponding public key, hashing algorithm and object can verify that the signature was created by the possessor of the private key and that the certificate has not been tampered with. +- __Signature Suite__: A two-part set consisting of an _authentication_ and _hash_ algorithm. Used to produce and validate _signatures_. + ### 1.3 Conventions The words __must__, __must not__, __required__, __should__, __should not__, __recommended__, __may__, and __optional__ in this document are to be interpreted as follows: __must__ and __required__ denote absolute requirements that must be adhered to for a certificate to be considered compliant to a given profile; __must not__ denotes an absolute prohibition; __should__, __should not__ and __recommended__ denote recommendations that should be deviated from only if special circumstances make it relevant; and, finally, __may__ and __optional__ denote something being truly optional. @@ -106,8 +122,7 @@ The ASN.1 syntax of the third version of the X.509 certificate format is defined The `Certificate` structure itself consists only of a `TBSCertificate`, a signature algorithm identifier and a concrete signature. The signature is meant to be produced by the issuer of the certificate and serves to protect the integrity of the certificate under the assumption that the issuer is trusted. -All data protected by the signature is collected in the `TBSCertificate`. -Each of its fields is described in the following subsections. +All data protected by the signature is collected in the `TBSCertificate`, the fields of which are described in the following subsections. #### 2.1.1 `version` @@ -127,10 +142,11 @@ Note that the serial number is signed and must be positive, which means that the #### 2.1.3 `signature` -An identifier associated with the cryptographic signature algorithm used to produce the `signatureValue` in the enclosing `Certificate`, as well as any parameters made relevant by the algorithm type. -Examples of algorithms could be _RSA with SHA256_ or _ED25519_. +Identifies the signature suite used to produce the `signatureValue` in the enclosing `Certificate`, as well as any parameters made relevant by the suite. +Examples of suites could be _RSA with SHA256_ or _ED25519_. +This field must contain the same suite as the `signatureAlorithm` field in the enclosing `Certificate`, as described in the beginning of Section 2.1. -This field must contain the same algorithm as the `signatureAlorithm` field in the enclosing `Certificate`, as described in the beginning of Section 2.1. +See Section 3 for information about selecting cryptographic algorithms. #### 2.1.4 `issuer` @@ -230,7 +246,7 @@ SubjectPublicKeyInfo ::= SEQUENCE { } ``` -See Section 3 for more information about what public key algorithms should be used and supported. +See Section 3 for information about selecting cryptographic algorithms. #### 2.1.8 `issuerUniqueID` and `subjectUniqueID` @@ -259,9 +275,10 @@ RFC 5280 explicitly outlines 17 different X.509 extensions, listed by category b | Extension | `extnID` (OID) | Brief Description | |:-----------------------------|:---------------------|:------------------| -| __Key Extensions__ | | +| __Identifier Extensions__ | | | Authority Key Identifier | `2.5.29.35` | Identifier uniquely associated with certificate issuer. | Subject Key Identifier | `2.5.29.14` | Identifier uniquely associated with certificate subject. +| __Key Usage Extensions__ | | | Key Usage | `2.5.29.15` | Public key usage restrictions. | Extended Key Usage | `2.5.29.37` | Additional public key usage restrictions. | __Policy Extensions__ | | @@ -285,7 +302,7 @@ RFC 5280 explicitly outlines 17 different X.509 extensions, listed by category b Each category of extensions is described in the following subsections. -#### 2.1.9.1 Key Extensions +#### 2.1.9.1 Identifier Extensions The __Authority Key Identifier__ and __Subject Key Identifier__ extensions are used to identify the public key of the issuer and subject of a given certificate, respectively. The extensions are defined as follows: @@ -312,6 +329,8 @@ RFC 5280 further _requires_ that all but end entity certificates use the `Subjec Its value _should_ be the the cryptographic hash of the `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field. The extensions _must not_ be marked as critical. +#### 2.1.9.2 Key Usage Extensions + The __Key Usage__ and __Extended Key Usage__ extensions are defined as follows: ```asn1 @@ -344,14 +363,13 @@ The `serverAuth` and `clientAuth` identifiers _must_ be included. The extension _should not_ be marked as _critical_. Other purpose identifiers _may_ be used. -#### 2.1.9.2 Policy Extensions +#### 2.1.9.3 Policy Extensions In the context of X.509 and RFC 5280, a _policy_ is a legal document that binds the owner of a certificate and, potentially, all certificates issued by that certificate to certain legal obligations. The four policy extensions defined by RFC 5280 _may_ be used to ensure that every certificate in a given certificate chain have accepted some policies of concern. Please refer to RFC 5280 for more details about these extensions. -Their use is _optional_. -#### 2.1.9.3 Name Extensions +#### 2.1.9.4 Name Extensions The __Subject Alternative Name__ and __Issuer Alternative Name__ allows for additional identities to be associated with a given `subject` or `issuer` name. Such additional identities significantly include DNS names, IP addresses and e-mail addresses. @@ -387,16 +405,16 @@ The extension _may_ be used. It _must_ be marked as critical if used. Please refer to RFC 5280 Section 4.2.1.10 for more details. -#### 2.1.9.4 CRL Extensions +#### 2.1.9.5 CRL Extensions The CRL extensions facilitate a mechanism for revoking certificates that are still valid and distributing information about those revocations. -These extensions _should not_ be used to facilitate the revocation of end entity certificates. -They _may_ be used for revoking CA certificates. +These extensions _should not_ be used to facilitate the revocation of on-On-Boarding, Device, System and Operator certificates. +They _may_ be used for revoking certificates of the other profiles. Eclipse Arrowhead comes with its own certificate revocation procedure via its _Certificate Authority_ system. Its use is _recommended_ for revoking and verifying the validity of On-Boarding, Device, System and Operator certificates. -#### 2.1.9.5 Information Extensions +#### 2.1.9.6 Information Extensions The information extensions allows various types of data sources or services to be associated with the certificate holder. These extensions _should not_ be used. @@ -404,7 +422,7 @@ These extensions _should not_ be used. Eclipse Arrowhead has its own provisions for metadata distribution and service management, via the _Service Registry_ system, _Gatekeeper_ system, and other. Those provisions _should_ be used. -#### 2.1.9.6 Other Extensions +#### 2.1.9.7 Other Extensions The __Subject Directory Attributes__ allows for arbitrary identification attributes, such as nationality, to be associated with the `subject` of a certificate. It _may_ be used. @@ -459,16 +477,16 @@ The following extensions _must_ be used and configured as described: |:-------------------------|:------------|:---------|:------| | Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. Omit field if self-signed. See Section 2.1.9.1. | Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. -| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2`. See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 2`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.2. If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. -| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. ### 2.3 Gate Profile @@ -495,10 +513,10 @@ The following extensions _must_ be used and configured as described: | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| | Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. -| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.1. -| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name through which the system can be reached. See Section 2.1.9.3. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name through which the system can be reached. See Section 2.1.9.4. ### 2.4 Organization Profile @@ -525,16 +543,16 @@ The following extensions _must_ be used and configured as described: |:-------------------------|:------------|:---------|:------| | Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. | Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. -| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1`. See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 1`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.2. If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. -| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. ### 2.5 Local Cloud Profile @@ -561,16 +579,16 @@ The following extensions _must_ be used and configured as described: |:-------------------------|:------------|:---------|:------| | Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. | Subject Key Identifier | `2.5.29.14` | No | Hash of subject public key. See Section 2.1.9.1. -| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0`. See Section 2.1.9.6. -| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: true, pathLenConstraint: 0`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `keyCertSign(5)` and `cRLSign(6)` _must_ be set. See Section 2.1.9.2. If the certificate will be used to automatically respond to CSRs via a network application interface, the following must also be present: | Extension | OID | Critical | Value | |:-------------------------|:------------|:---------|:------| -| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.1. -| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.1. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.3. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. ### 2.6 On-Boarding Profile @@ -583,9 +601,9 @@ If the certificate will be used to automatically respond to CSRs via a network a ## 3. Algorithms, Key Lengths and Other Security Details Choosing a signature scheme for a certificate poorly can lead to severe security vulnerabilities. -We _recommend_ that relevant recommendations of credible information security institutes, such as NIST, ENSIA or IETF, be consulted for making choices about algorithms, key lengths and other relevant security details. +We _recommend_ that credible information security institutes, such as NIST, ENSIA or IETF, be consulted for making choices about algorithms, key lengths and other relevant security details. -Given that no relevant breakthroughs are made or expected in quantum computing, you _may_ chose to follow RFC 7525, which recommends the following four TLS _cipher suites_: +Given that no relevant breakthroughs are made or expected in quantum computing, you _may_ chose to follow RFC 7525, which recommends the following four TLS cipher suites: | Key Exchange | Authentication | Encryption | Hash | |:-------------|:-------------------|:------------|:-------| @@ -594,10 +612,6 @@ Given that no relevant breakthroughs are made or expected in quantum computing, | DHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | | ECDHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | -Note that all TLS versions prior to 1.2 are deprecated, as per RFC 8996. -A cipher suite is a collection of cryptographic algorithm used to establish secure connections over untrusted transports. -The _Authentication_ and _Hash_ algorithms of a cipher suite constitute what is referred to as a _signature scheme_, which must be specified in and used with every created X.509 certificate, as mentioned in Section 2.1.3. - The above recommendations are _general_, in the sense that no particular assumptions are made about the setting in which the device employing the signature or cipher suite is located. We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. From 97260f676d18cde06f2735c74e06ab02d0613981 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Tue, 24 Aug 2021 14:04:21 +0200 Subject: [PATCH 29/36] Work on proposal.md --- proposal.md | 133 ++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 125 insertions(+), 8 deletions(-) diff --git a/proposal.md b/proposal.md index a0e4f00..8f74881 100644 --- a/proposal.md +++ b/proposal.md @@ -75,7 +75,7 @@ Used in tandem with X.509 to establish that the identities of any connecting par - __Public key__: The public component of a public/private key pair. Knowledge of the public key allows for messages to be encrypted such that only the possessor of the private key can decrypt them, and vice versa. Used to produce _signatures_ and to _share secrets_. - __Shared Secret__: The input to an _encryption algorithm_ that has been shared between two parties such that no other party can see it. - __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Any party with the corresponding public key, hashing algorithm and object can verify that the signature was created by the possessor of the private key and that the certificate has not been tampered with. -- __Signature Suite__: A two-part set consisting of an _authentication_ and _hash_ algorithm. Used to produce and validate _signatures_. +- __Signature Suite__: A two-part set consisting of an _authentication_ and _hash_ algorithm. Used to produce and validate _signatures_. Can be a subset of a _cipher suite_. ### 1.3 Conventions @@ -173,7 +173,7 @@ Time ::= CHOICE { For each of these two dates, the date in question _must_ be encoded as a `UTCTime` if its year is less than or equal to 2049, or as a `GeneralizedTime` if the year is equal to or greater than 2050. See Section 4.1.2.5 of RFC 5280 for more details. -The time span denoted by this field _should_ be shorter than the expected lifetime of the entity owning it, if provisions exist for renewing it during its lifetime. +The time span denoted by this field _should_ be shorter than the expected lifetime of the entity owning it, typically significantly shorter, if provisions exist for renewing it during its lifetime. More specific recommendations will be published in other documents of the Eclipse Arrowhead project. #### 2.1.6 `subject` @@ -227,9 +227,9 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. | State or Province Name | `ST` | `2.5.4.8` Every certificate _must_ contain exactly one `subject` _Distinguished Name Qualifier_ (`DN`) that identifies the profile it adheres to. -The actual identifiers are stated in Sections 2.2 to 2.10. +The actual identifiers are stated in Sections 2.2 to 2.9. -In addition, each certificates _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +In addition, each certificate _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. Note that DNS labels _must not_ contain dots, or any other character than the alphanumeric and dash. While names _may_ use 62 characters, we _recommend_ that names be kept at 20 characters or less. The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA with same Distinguished Name Qualifier (`DN`). @@ -486,7 +486,7 @@ If the certificate will be used to automatically respond to CSRs via a network a |:-------------------------|:------------|:---------|:------| | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. | Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier to which CSRs can be sent. See Section 2.1.9.4. ### 2.3 Gate Profile @@ -516,7 +516,7 @@ The following extensions _must_ be used and configured as described: | Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. | Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name through which the system can be reached. See Section 2.1.9.4. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier through which the system can be reached. See Section 2.1.9.4. ### 2.4 Organization Profile @@ -552,7 +552,7 @@ If the certificate will be used to automatically respond to CSRs via a network a |:-------------------------|:------------|:---------|:------| | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. | Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier to which CSRs can be sent. See Section 2.1.9.4. ### 2.5 Local Cloud Profile @@ -588,16 +588,131 @@ If the certificate will be used to automatically respond to CSRs via a network a |:-------------------------|:------------|:---------|:------| | Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set in addition to `5` and `6`. See Section 2.1.9.2. | Extended Key Usage | `2.5.29.37` | No | Purposes`serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. -| Subject Alternative Name | `2.5.29.17` | No | At least one IP address or DNS name to which CSRs can be sent. See Section 2.1.9.4. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier to which CSRs can be sent. See Section 2.1.9.4. ### 2.6 On-Boarding Profile +An _On-Boarding_ certificate allows for a device in an Arrowhead local cloud to request a new device certificate. +It is used both or either to provision new devices and/or to facilitate renewal of certificates as they are about to expire. +Certificates adhering to this profile _must_ only be provided to devices known or assumed to be trustworthy. + +#### 2.3.1 `issuer` + +_Must_ be issued by a Local Cloud certificate. + +#### 2.3.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `onboarding`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label. See Section 2.1.6. _Should_ be an at lest 12 character long lowercase alphanumeric identifier, such as `51e41vjoxq8y`, created with a secure random number generator.* + +* Given an alphabet of 36 characters (a-z and 0-9), a 12 character identifier provides a search space of close to that of a 62-bit number. + In many contexts, this will be enough to hide the number of on-boarding certificates that have been issued by the same local cloud from an adversary with a copy of the certificate. + +#### 2.3.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier through which the owning device can be reached. See Section 2.1.9.4. + ### 2.7 Device Profile +A _Device_ certificate allows for a device in an Arrowhead local cloud to request new system certificates. +One system certificate is required for each system a given device intends to run. +Certificates adhering to this profile _must_ only be provided to devices known or assumed to be trustworthy. + +#### 2.3.1 `issuer` + +_Must_ be issued by a Local Cloud certificate. + +#### 2.3.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `device`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `srv-1642`. See Section 2.1.6. + +#### 2.3.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier through which the device can be reached. See Section 2.1.9.4. + ### 2.8 System Profile +A _System_ certificate allows for a device in an Arrowhead local cloud to provide the services associated with a particular system, and/or to act as a service consumer. + +#### 2.3.1 `issuer` + +_Must_ be issued by a Local Cloud certificate. + +#### 2.3.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `system`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `orch-0037`. See Section 2.1.6. + +#### 2.3.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier through which the system can be reached. See Section 2.1.9.4. + ### 2.9 Operator Profile +An _Operator_ certificate allows for a human or computer operator to administer a particular Arrowhead local cloud. + +#### 2.3.1 `issuer` + +_Must_ be issued by a Local Cloud certificate. + +#### 2.3.2 `subject` + +The subject field DN _must_ contain the following attributes exactly once, either in the same or different RDNs: + +| Attribute Type | OID | Value | +|:------------------|:-----------|:------| +| DN Qualifier (DN) | `2.5.4.46` | `operator`. +| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `15-b32-a`. See Section 2.1.6. + +#### 2.3.3 `extensions` + +The following extensions _must_ be used and configured as described: + +| Extension | OID | Critical | Value | +|:-------------------------|:------------|:---------|:------| +| Authority Key Identifier | `2.5.29.35` | No | Hash of issuer public key. See Section 2.1.9.1. +| Basic Constraints | `2.5.29.19` | Yes | `cA: false`. See Section 2.1.9.7. +| Key Usage | `2.5.29.15` | Yes | Bits `digitalSignature(0)` and `keyEncipherment(2)` _must_ be set. See Section 2.1.9.2. +| Extended Key Usage | `2.5.29.37` | No | Purposes `serverAuth` and `clientAuth` _must_ be specified. See Section 2.1.9.2. +| Subject Alternative Name | `2.5.29.17` | No | At least one IP address, DNS name or other identifier through which the operator's control system can be reached. See Section 2.1.9.4. + ## 3. Algorithms, Key Lengths and Other Security Details Choosing a signature scheme for a certificate poorly can lead to severe security vulnerabilities. @@ -637,3 +752,5 @@ However, as mobility at a scale that makes this setup a problem is currently dee It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. ## References + +TODO \ No newline at end of file From e71cd9a7c85fe8285d4814ff0b7143308edaaa82 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 25 Aug 2021 09:56:43 +0200 Subject: [PATCH 30/36] Work on proposal.md --- proposal.md | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/proposal.md b/proposal.md index 8f74881..5bd3dbd 100644 --- a/proposal.md +++ b/proposal.md @@ -64,17 +64,17 @@ The standard is used to describe the structure of X.509 certificates, which _mus #### 1.2.5 TLS _Transport Layer Security_ (TLS), an IETF (Internet Engineering Task-Force) standard for establishing secure connection over untrusted transports. -Used in tandem with X.509 to establish that the identities of any connecting parties can be mutually authenticated. +Used in tandem with X.509 to establish that the identities of any connecting parties can be authenticated. - __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a counter-party. -- __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. -- __Encryption Algorithm__: A symmetric encryption algorithm, typically used to make data opaque in transit between a sender and a recipient. Also referred to as _stream_ or _block_ cipher, depending on its mode of operation. +- __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. The _authentication_ and _hash_ algorithms form a _signature suite_. +- __Encryption Algorithm__: A symmetric encryption algorithm, typically used to make data opaque in transit between a sender and a recipient. Can also be referred to as a _stream_ or _block_ cipher, depending on its mode of operation. - __Key Exchange Algorithm__: An algorithm used by parties for exchanging _public keys_ as part of preparing for secure communication. -- __Hash Algorithm__: A function that produces an arbitrary fixed-size output for any given arbitrarily sized input. The same input always produces the same output. Used to reduce the size of public key signatures. +- __Hash Algorithm__: A function that produces an arbitrary fixed-size output for any given arbitrarily sized input. The same input always produces the same output. Used to reduce the size of public key signatures, among other things. - __Party__: Either end of a two-way communication. - __Public key__: The public component of a public/private key pair. Knowledge of the public key allows for messages to be encrypted such that only the possessor of the private key can decrypt them, and vice versa. Used to produce _signatures_ and to _share secrets_. - __Shared Secret__: The input to an _encryption algorithm_ that has been shared between two parties such that no other party can see it. -- __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Any party with the corresponding public key, hashing algorithm and object can verify that the signature was created by the possessor of the private key and that the certificate has not been tampered with. +- __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Any party with the corresponding public key, hashing algorithm and hashed object can verify that the signature was created by the possessor of the private key and that the object has not been tampered with. - __Signature Suite__: A two-part set consisting of an _authentication_ and _hash_ algorithm. Used to produce and validate _signatures_. Can be a subset of a _cipher suite_. ### 1.3 Conventions @@ -731,7 +731,30 @@ The above recommendations are _general_, in the sense that no particular assumpt We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. -## 4. Certificate Creation and Distribution +## 4. Certificate Life-Cycle Management + +Certificates must be created, distributed, replaced as they expire and, sometimes, revoked before they expire. +If these tasks are handled without care, it can lead to serious security vulnerabilities. +To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing certificate life-cycles within local clouds. +We _recommend_ that the system be used for all Eclipse Arrowhead installations, whenever possible. + +There are, however, certificate profiles that fall outside the scope of the local cloud. +Furthermore, there may be contexts in which using a Certificate Authority is unfeasible. +In such cases, we _recommend_ that the following be observed: + +1. Each private key _should_ be created on the device that will use it and no copies of it are ever shared with any other device, system or other entity. + - This means that CSRs _should_ be used for every certificate issuance. CSRs can be created and handled both automatically and manually. + - As an exception, if a created certificate is a Master or Organization certificate, we _recommend_ that backups be kept such that key data, including private keys, are not lost in the case of hardware failure or other adversarial conditions. Such backups _should_ be guarded with outmost care. +2. Private keys _should_ be stored in hardware memory that is designed to resist tampering and key theft. + - This could, for example, be achieved by using Trusted Platform Modules (TPMs), also known as ISO/IEC 11889. +3. If there is any suspicion about a private key being compromised, the corresponding certificate _should_ be revoked and replaced as soon as possible. +4. Provisions _should_ be in place for ensuring that no relevant certificate chains contains revoked certificates. + - If a managed entity has a revoked certificate in its certificate chain, the chain _should_ be replaced with a valid such as soon as possible. + - If an external entity has a revoked certificate in its certificate chain, it _should not_ be interacted with. + +The above list is _not_ to be considered as being exhaustive. +Adhering to it is not a substitute for consulting independent and credible security experts about every specific use case scenario. +The list is likely to be revised in the future as more core systems are introduced by the Eclipse Arrowhead project. ## 5. Authentication and Authorization From 1ae258581e70bd49a3cace008263ae37a21d2ae3 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Wed, 25 Aug 2021 16:11:01 +0200 Subject: [PATCH 31/36] Work on proposal.md --- proposal.md | 117 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 72 insertions(+), 45 deletions(-) diff --git a/proposal.md b/proposal.md index 5bd3dbd..e463a14 100644 --- a/proposal.md +++ b/proposal.md @@ -36,6 +36,8 @@ Certificate standard for establishing trust between devices over untrusted compu - __Certificate Signing Request (CSR)__: A request for a certificate to be issued by a receiving CA. - __End Entity__: Entity having but not issuing certificates. - __Entity__: Any thing or being potentially able to hold and use an X.509 certificate. +- __Fingerprint__: The hash of the DER form of an X.509 certificate, produced using a cryptographic _hash algorithm_. +- __Hash Algorithm__: A function that produces an arbitrary fixed-size output for any given arbitrarily sized input. The same input always produces the same output. - __Intermediary CA__: CA that _did not_ issue its own certificate and, therefore, can be trusted by explicitly trusting another certificate further up its issuance hierarchy. - __Issuer__: The CA that signed a given certificate. - __Public Key Infrastructure (PKI)__: The structure of entities, each having a certain role, required to facilitate secure certificate distribution. @@ -226,13 +228,31 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. | Serial Number | `SN` | `2.5.4.5` | State or Province Name | `ST` | `2.5.4.8` -Every certificate _must_ contain exactly one `subject` _Distinguished Name Qualifier_ (`DN`) that identifies the profile it adheres to. -The actual identifiers are stated in Sections 2.2 to 2.9. - -In addition, each certificate _must_ contain exactly one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. -Note that DNS labels _must not_ contain dots, or any other character than the alphanumeric and dash. -While names _may_ use 62 characters, we _recommend_ that names be kept at 20 characters or less. +Every certificate _must_ contain at least one `subject` _Distinguished Name Qualifier_ (`DN`). +It _should_ only contain one. +The rightmost (i.e. least significant) such identifies the profile of the certificate. +The identifiers are as follows: + +| X.509 Profile | Distinguished Name Qualifier (`DN`) | +|:--------------|:------------------------------------| +| Master | `ma` +| Gate | `ga` +| Organization | `or` +| Local Cloud | `lo` +| On-Boarding | `on` +| Device | `de` +| System | `sy` +| Operator | `op` + +In addition, each certificate _must_ contain at least one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. +It _should_ only contain one. +The rightmost (i.e. least significant) such contains the human name of the certificate. +While names _may_ use 62 characters, we _recommend_ that the name be a 10 to 20 character long lowercase identifier, such as `51e41vjoxq`, produced with a secure random number generator. +Randomized identifiers hide details that otherwise would become accessible to adversaries with certificate copies, such as how many certificates have been issued, the type of machines they are associated with, and so on. The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA with same Distinguished Name Qualifier (`DN`). +It _should not_ be derived from a portion of the `serialNumber` of the same certificate. +The `CN` is meant to help humans refer to specific certificate owners, they _should not_ be used as primary references by machines. +See Section 4 for a discussion about machine certificate references. #### 2.1.7 `subjectPublicKeyInfo` @@ -466,8 +486,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `master`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `ltu-rsa-2021`. +| DN Qualifier (DN) | `2.5.4.46` | `ma` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.2.3 `extensions` @@ -503,8 +523,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `gate`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `mqtt-04`. See Section 2.1.6. +| DN Qualifier (DN) | `2.5.4.46` | `ga` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.3.3 `extensions` @@ -532,8 +552,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `organization`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `company-rsa-2021`. +| DN Qualifier (DN) | `2.5.4.46` | `or` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.4.3 `extensions` @@ -568,8 +588,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `localcloud`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `pumping-station-04`. +| DN Qualifier (DN) | `2.5.4.46` | `lo`. +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.4.3 `extensions` @@ -606,11 +626,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `onboarding`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label. See Section 2.1.6. _Should_ be an at lest 12 character long lowercase alphanumeric identifier, such as `51e41vjoxq8y`, created with a secure random number generator.* - -* Given an alphabet of 36 characters (a-z and 0-9), a 12 character identifier provides a search space of close to that of a 62-bit number. - In many contexts, this will be enough to hide the number of on-boarding certificates that have been issued by the same local cloud from an adversary with a copy of the certificate. +| DN Qualifier (DN) | `2.5.4.46` | `on`. +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.3.3 `extensions` @@ -640,8 +657,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `device`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `srv-1642`. See Section 2.1.6. +| DN Qualifier (DN) | `2.5.4.46` | `de` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.3.3 `extensions` @@ -669,8 +686,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `system`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `orch-0037`. See Section 2.1.6. +| DN Qualifier (DN) | `2.5.4.46` | `sy` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.3.3 `extensions` @@ -698,8 +715,8 @@ The subject field DN _must_ contain the following attributes exactly once, eithe | Attribute Type | OID | Value | |:------------------|:-----------|:------| -| DN Qualifier (DN) | `2.5.4.46` | `operator`. -| Common Name (CN) | `2.5.4.3` | A valid DNS name label, such as `15-b32-a`. See Section 2.1.6. +| DN Qualifier (DN) | `2.5.4.46` | `op` +| Common Name (CN) | `2.5.4.3` | Randomized identifier. See Section 2.1.6. #### 2.3.3 `extensions` @@ -731,43 +748,53 @@ The above recommendations are _general_, in the sense that no particular assumpt We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. -## 4. Certificate Life-Cycle Management +## 4. Identifying Certificates and Their Owners + +The X.509 profiles of this document provide two fields and one extension whose values could be used to identify a particular certificate or its owner. +These are the the `serialNumber` and `subject` fields, as well as the `Subject Key Identifier` extension. +Despite this, they _must not_ be used by machines referring to certificates. +The reason for this is that they are all set arbitrarily by the creator of each certificate. +An adversary with a given certificate could create another certificate with the same values, allowing it to masquerade as the owner of the original certificate without knowledge of its private key. + +What _should_ be used, rather, is either (1) the cryptographic hash of an entire certificate in DER form (i.e. its fingerprint) or (2) the cryptographic hash of its `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field, also in its DER form. +While the second of these two identifiers will be equal to the `Subject Key Identifier` for a conformant certificate, it _should not_ be generally assumed that a given certificate is conformant. +Both of these hashes include the public key of the certificate owner, which means that it becomes harder for an adversary to create a counterfeit certificate. +We _recommend_ that the certificate hash (fingerprint) be generally used as identifier, as it protects the integrity of the entire certificate as opposed to only one field of it. +See Section 3 for details about what hash algorithms to use. + +## 5. Certificate Life-Cycle Management Certificates must be created, distributed, replaced as they expire and, sometimes, revoked before they expire. If these tasks are handled without care, it can lead to serious security vulnerabilities. -To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing certificate life-cycles within local clouds. +To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing the certificate life-cycle within a local clouds. We _recommend_ that the system be used for all Eclipse Arrowhead installations, whenever possible. -There are, however, certificate profiles that fall outside the scope of the local cloud. -Furthermore, there may be contexts in which using a Certificate Authority is unfeasible. -In such cases, we _recommend_ that the following be observed: +Generally, when certificate life-cycles are managed, we _recommend_ that the following be observed: -1. Each private key _should_ be created on the device that will use it and no copies of it are ever shared with any other device, system or other entity. - - This means that CSRs _should_ be used for every certificate issuance. CSRs can be created and handled both automatically and manually. - - As an exception, if a created certificate is a Master or Organization certificate, we _recommend_ that backups be kept such that key data, including private keys, are not lost in the case of hardware failure or other adversarial conditions. Such backups _should_ be guarded with outmost care. -2. Private keys _should_ be stored in hardware memory that is designed to resist tampering and key theft. - - This could, for example, be achieved by using Trusted Platform Modules (TPMs), also known as ISO/IEC 11889. -3. If there is any suspicion about a private key being compromised, the corresponding certificate _should_ be revoked and replaced as soon as possible. -4. Provisions _should_ be in place for ensuring that no relevant certificate chains contains revoked certificates. - - If a managed entity has a revoked certificate in its certificate chain, the chain _should_ be replaced with a valid such as soon as possible. - - If an external entity has a revoked certificate in its certificate chain, it _should not_ be interacted with. +1. Create each private key on the device that will use it. +2. Use CSRs to avoid moving private keys between devices during certificate issuance. +3. Never make backups or other copies of private keys that can be trivially replaced. +4. Store backups of sensitive private keys offline, if possible. +5. Store active private keys in secure hardware elements, such as TPMs (ISO/IEC 11889). +6. Immediately revoke owned certificates whose private keys are suspected to be compromised. +7. Actively look for and act on revocations in the certificate chains of counter-parties. The above list is _not_ to be considered as being exhaustive. -Adhering to it is not a substitute for consulting independent and credible security experts about every specific use case scenario. -The list is likely to be revised in the future as more core systems are introduced by the Eclipse Arrowhead project. +Adhering to it is not a substitute for consulting independent and credible security experts. +The list is likely to be revised as more experience is gained related to the security of Arrowhead installations. -## 5. Authentication and Authorization +## 6. Authentication and Authorization __Precedence__. Being _hierarchical_, a DN describes a path from some arbitrary root to the subject or issuer in question, where the root is the leftmost RDN and the subject or issuer is the rightmost. The root does not have to be associated with the root CA of the certificate in question. While the above listed attributes _should not_ appear more than once in a subject or issuer DN, if they do, the rightmost takes precedence during the authorization procedure described in Section 6. -## 6. DNS Support and its Security Implications +## 7. DNS Support and its Security Implications -## 7. Known Limitations +## 8. Known Limitations -### 7.1 Subject Alternative Names and Device Mobility +### 8.1 Subject Alternative Names and Device Mobility Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. From 6dcdb33aed32e1fea5455db88c69adfa4fdef3e9 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 26 Aug 2021 09:53:38 +0200 Subject: [PATCH 32/36] Work on proposal.md --- proposal.md | 59 ++++++++++++++++++++++++++++------------------------- 1 file changed, 31 insertions(+), 28 deletions(-) diff --git a/proposal.md b/proposal.md index e463a14..8aa0338 100644 --- a/proposal.md +++ b/proposal.md @@ -245,13 +245,14 @@ The identifiers are as follows: | Operator | `op` In addition, each certificate _must_ contain at least one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. -It _should_ only contain one. -The rightmost (i.e. least significant) such contains the human name of the certificate. -While names _may_ use 62 characters, we _recommend_ that the name be a 10 to 20 character long lowercase identifier, such as `51e41vjoxq`, produced with a secure random number generator. +It _should_ only contain one `CN`. +The rightmost (i.e. least significant) such contains the name, or _alias_, meant to be used by humans when referring to the certificate. +While names _may_ use up to 62 characters, we _recommend_ the use of 10 to 20 character long lowercase identifiers, such as `51e41vjoxq`, produced with secure random number generators. Randomized identifiers hide details that otherwise would become accessible to adversaries with certificate copies, such as how many certificates have been issued, the type of machines they are associated with, and so on. The `CN` field value _must_, furthermore, be unique among all certificates issued by the same CA with same Distinguished Name Qualifier (`DN`). It _should not_ be derived from a portion of the `serialNumber` of the same certificate. -The `CN` is meant to help humans refer to specific certificate owners, they _should not_ be used as primary references by machines. + +The `CN` is meant to help humans refer to specific certificates, they _should not_ be used as primary references by machines. See Section 4 for a discussion about machine certificate references. #### 2.1.7 `subjectPublicKeyInfo` @@ -273,9 +274,7 @@ See Section 3 for information about selecting cryptographic algorithms. Optional identifiers uniquely associated with the issuer or subject of the certificate. These fields _must not_ be used. -When a certain certificate, or its subject, needs to be identified, the cryptographic hash of the certificate, or its _fingerprint_, _should_ be used. -If desired to identify the subject by its public key, which _may_ be used in multiple certificates, the cryptographic hash of the `subjectPublicKey` field (excluding the tag, length, and number of unused bits) of `subjectPublicKeyInfo` _should_ be used. -See Section 3 for more information about what hashing algorithms should be used for this and other purposes. +See Section 4 for a discussion about certificate identification. #### 2.1.9 `extensions` @@ -331,8 +330,8 @@ The extensions are defined as follows: -- Required for all but self-signed CA certificates (root CAs). AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifier OPTIONAL, -- Required. - authorityCertIssuer [1] GeneralNames OPTIONAL, -- Optional. - authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL -- Optional. + authorityCertIssuer [1] GeneralNames OPTIONAL, -- Should not be used. + authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL -- Should not be used. } -- Required for all but end entity certificates. @@ -347,6 +346,7 @@ Use of the `authorityCertIssuer` and `authorityCertSerialNumber` fields of `Auth If a self-signed certificate leaves the `authorityCertIssuer` and `authorityCertSerialNumber` fields unspecified, it may omit the `AuthorityKeyIdentifier` extension entirely. RFC 5280 further _requires_ that all but end entity certificates use the `SubjectKeyIdentifier` extension. Its value _should_ be the the cryptographic hash of the `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field. +See Section 3 for a discussion about what hash algorithms to use. The extensions _must not_ be marked as critical. #### 2.1.9.2 Key Usage Extensions @@ -371,7 +371,7 @@ ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER ``` -The `KeyUsage` extension is a set of bit flags used to indicate various ways in which a certificate _may_ be used. +The `KeyUsage` extension is a set of bit flags indicating various ways in which a certificate _must_ only be used. Please refer to RFC 5280 Section 4.2.1.3 for descriptions of each bit flag. The extension _must_ be used in all certificates and _must_ be marked as critical. How to set it is outlined in the section specific to each particular certificate profile. @@ -385,7 +385,7 @@ Other purpose identifiers _may_ be used. #### 2.1.9.3 Policy Extensions -In the context of X.509 and RFC 5280, a _policy_ is a legal document that binds the owner of a certificate and, potentially, all certificates issued by that certificate to certain legal obligations. +In the context of X.509 and RFC 5280, a _policy_ is a legal document that binds the owner of a certificate, and, potentially, all certificates issued by that certificate, to certain legal obligations. The four policy extensions defined by RFC 5280 _may_ be used to ensure that every certificate in a given certificate chain have accepted some policies of concern. Please refer to RFC 5280 for more details about these extensions. @@ -415,20 +415,26 @@ GeneralName ::= CHOICE { } ``` -The `SubjectAltName` extension _must_ be used by all end entity certificates and _must_ identify at least one DNS name or IP address. +The `SubjectAltName` extension _must_ be used by all end entity certificates and _must_ identify at least one DNS name, IP address or other relevant identifier useful for contacting the certificate owner. The extension _must_ also be used for CA certificates that handles CSRs directly via network application interfaces. -Use of the `IssuerAltName` is _optional_. +Use of the `IssuerAltName` is _not recommended_. Both extensions _should_ be marked as non-critical. +__Security recommendation__. +All names appearing in a `SubjectAltName` extension _should_ be randomized, by which we mean that every name is formulated such that an adversary can derive as little information as possible from it. +In the case of an IP address, this means that a larger address space is preferred (e.g. 10.0.0.0/8 rather than 192.168.0.0/16) and that addresses are assigned randomly rather than sequentially. +In the case of DNS names, this means that no serially assigned identifiers are used and that no human-readable descriptors of sensitive places or things are part of the name. +See Section 7 for a discussion about the use of DNS in the context of Arrowhead. + The __Name Constraints__ extension makes it possible for a CA to restrict the set of values allowed for the `subject` and `SubjectAltName` fields in issued certificates. -The extension _may_ be used. +The extension _should not_ be used. It _must_ be marked as critical if used. Please refer to RFC 5280 Section 4.2.1.10 for more details. #### 2.1.9.5 CRL Extensions The CRL extensions facilitate a mechanism for revoking certificates that are still valid and distributing information about those revocations. -These extensions _should not_ be used to facilitate the revocation of on-On-Boarding, Device, System and Operator certificates. +These extensions _should not_ be used to facilitate the revocation of On-Boarding, Device, System and Operator certificates. They _may_ be used for revoking certificates of the other profiles. Eclipse Arrowhead comes with its own certificate revocation procedure via its _Certificate Authority_ system. @@ -436,7 +442,7 @@ Its use is _recommended_ for revoking and verifying the validity of On-Boarding, #### 2.1.9.6 Information Extensions -The information extensions allows various types of data sources or services to be associated with the certificate holder. +The information extensions allows for various types of data sources or services to be associated with the certificate holder. These extensions _should not_ be used. Eclipse Arrowhead has its own provisions for metadata distribution and service management, via the _Service Registry_ system, _Gatekeeper_ system, and other. @@ -732,7 +738,7 @@ The following extensions _must_ be used and configured as described: ## 3. Algorithms, Key Lengths and Other Security Details -Choosing a signature scheme for a certificate poorly can lead to severe security vulnerabilities. +Choosing a signature suite for a certificate poorly can lead to severe security vulnerabilities. We _recommend_ that credible information security institutes, such as NIST, ENSIA or IETF, be consulted for making choices about algorithms, key lengths and other relevant security details. Given that no relevant breakthroughs are made or expected in quantum computing, you _may_ chose to follow RFC 7525, which recommends the following four TLS cipher suites: @@ -744,6 +750,10 @@ Given that no relevant breakthroughs are made or expected in quantum computing, | DHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | | ECDHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | +Each cipher suite includes a signature suite (the _Authentication_ and _Hash_ fields). +Adhering to RFC 7525 means that RSA (2048-bit or 3072-bit) with SHA256 or SHA384 is used to sign certificates. +Given that RFC 7525 is trusted, SHA256 and SHA384 _may_ be suitable choices for producing certificate identifiers, as discussed in Section 4. + The above recommendations are _general_, in the sense that no particular assumptions are made about the setting in which the device employing the signature or cipher suite is located. We understand that many Arrowhead installations will involve hardware with limited computational capabilities, which may not be able to handle primitives of the cryptographic strengths we have mentioned. The Eclipse Arrowhead project will publish summaries of recommendations for such and other settings in the future. @@ -756,7 +766,7 @@ Despite this, they _must not_ be used by machines referring to certificates. The reason for this is that they are all set arbitrarily by the creator of each certificate. An adversary with a given certificate could create another certificate with the same values, allowing it to masquerade as the owner of the original certificate without knowledge of its private key. -What _should_ be used, rather, is either (1) the cryptographic hash of an entire certificate in DER form (i.e. its fingerprint) or (2) the cryptographic hash of its `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field, also in its DER form. +What _should_ be used, rather, is either (1) the cryptographic hash of an entire certificate in its DER form (i.e. its fingerprint) or (2) the cryptographic hash of its `subjectPublicKey` value (excluding the tag, length, and number of unused bits) of the `subjectPublicKeyInfo` field, also in its DER form. While the second of these two identifiers will be equal to the `Subject Key Identifier` for a conformant certificate, it _should not_ be generally assumed that a given certificate is conformant. Both of these hashes include the public key of the certificate owner, which means that it becomes harder for an adversary to create a counterfeit certificate. We _recommend_ that the certificate hash (fingerprint) be generally used as identifier, as it protects the integrity of the entire certificate as opposed to only one field of it. @@ -767,7 +777,7 @@ See Section 3 for details about what hash algorithms to use. Certificates must be created, distributed, replaced as they expire and, sometimes, revoked before they expire. If these tasks are handled without care, it can lead to serious security vulnerabilities. To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing the certificate life-cycle within a local clouds. -We _recommend_ that the system be used for all Eclipse Arrowhead installations, whenever possible. +We _recommend_ that the system be used, or a similarly capable replacement, for all Eclipse Arrowhead installations, whenever possible. Generally, when certificate life-cycles are managed, we _recommend_ that the following be observed: @@ -783,18 +793,11 @@ The above list is _not_ to be considered as being exhaustive. Adhering to it is not a substitute for consulting independent and credible security experts. The list is likely to be revised as more experience is gained related to the security of Arrowhead installations. -## 6. Authentication and Authorization - -__Precedence__. -Being _hierarchical_, a DN describes a path from some arbitrary root to the subject or issuer in question, where the root is the leftmost RDN and the subject or issuer is the rightmost. -The root does not have to be associated with the root CA of the certificate in question. -While the above listed attributes _should not_ appear more than once in a subject or issuer DN, if they do, the rightmost takes precedence during the authorization procedure described in Section 6. +## 6. TLS Authentication and Authorization ## 7. DNS Support and its Security Implications -## 8. Known Limitations - -### 8.1 Subject Alternative Names and Device Mobility +## 8. Subject Alternative Names and Device Mobility Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. From 4d8057b12500af023a0cf0fd2fdce1f1a421f168 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 26 Aug 2021 16:38:46 +0200 Subject: [PATCH 33/36] Work on proposal.md --- proposal.md | 54 ++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 11 deletions(-) diff --git a/proposal.md b/proposal.md index 8aa0338..b03e26c 100644 --- a/proposal.md +++ b/proposal.md @@ -68,15 +68,15 @@ The standard is used to describe the structure of X.509 certificates, which _mus _Transport Layer Security_ (TLS), an IETF (Internet Engineering Task-Force) standard for establishing secure connection over untrusted transports. Used in tandem with X.509 to establish that the identities of any connecting parties can be authenticated. -- __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a counter-party. +- __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a peer. - __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. The _authentication_ and _hash_ algorithms form a _signature suite_. - __Encryption Algorithm__: A symmetric encryption algorithm, typically used to make data opaque in transit between a sender and a recipient. Can also be referred to as a _stream_ or _block_ cipher, depending on its mode of operation. - __Key Exchange Algorithm__: An algorithm used by parties for exchanging _public keys_ as part of preparing for secure communication. - __Hash Algorithm__: A function that produces an arbitrary fixed-size output for any given arbitrarily sized input. The same input always produces the same output. Used to reduce the size of public key signatures, among other things. -- __Party__: Either end of a two-way communication. +- __Peer__: Either end of a two-way communication. - __Public key__: The public component of a public/private key pair. Knowledge of the public key allows for messages to be encrypted such that only the possessor of the private key can decrypt them, and vice versa. Used to produce _signatures_ and to _share secrets_. -- __Shared Secret__: The input to an _encryption algorithm_ that has been shared between two parties such that no other party can see it. -- __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Any party with the corresponding public key, hashing algorithm and hashed object can verify that the signature was created by the possessor of the private key and that the object has not been tampered with. +- __Shared Secret__: The input to an _encryption algorithm_ that has been secretly shared between two parties. +- __Signature__: The private key encryption of a hashed object, which most significantly can be an X.509 certificate. Knowledge of the corresponding public key, hashing algorithm and hashed object can is sufficient to verify that the signature was created by the possessor of the private key and that the object has not been tampered with. - __Signature Suite__: A two-part set consisting of an _authentication_ and _hash_ algorithm. Used to produce and validate _signatures_. Can be a subset of a _cipher suite_. ### 1.3 Conventions @@ -230,6 +230,7 @@ See RFC 5280 Section 4.1.2.4 for more attributes that _should_ be supported. Every certificate _must_ contain at least one `subject` _Distinguished Name Qualifier_ (`DN`). It _should_ only contain one. +It _should_ be encoded as a `PrintableString`. The rightmost (i.e. least significant) such identifies the profile of the certificate. The identifiers are as follows: @@ -246,6 +247,7 @@ The identifiers are as follows: In addition, each certificate _must_ contain at least one `subject` _Common Name_ (`CN`) that is a valid DNS label (https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1) of no more than 62 characters. It _should_ only contain one `CN`. +It _should_ be encoded as a `PrintableString`. The rightmost (i.e. least significant) such contains the name, or _alias_, meant to be used by humans when referring to the certificate. While names _may_ use up to 62 characters, we _recommend_ the use of 10 to 20 character long lowercase identifiers, such as `51e41vjoxq`, produced with secure random number generators. Randomized identifiers hide details that otherwise would become accessible to adversaries with certificate copies, such as how many certificates have been issued, the type of machines they are associated with, and so on. @@ -743,15 +745,16 @@ We _recommend_ that credible information security institutes, such as NIST, ENSI Given that no relevant breakthroughs are made or expected in quantum computing, you _may_ chose to follow RFC 7525, which recommends the following four TLS cipher suites: -| Key Exchange | Authentication | Encryption | Hash | -|:-------------|:-------------------|:------------|:-------| -| DHE | RSA (2048 or 3072) | AES 128 GCM | SHA256 | -| ECDHE | RSA (2048 or 3072) | AES 128 GCM | SHA256 | -| DHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | -| ECDHE | RSA (2048 or 3072) | AES 256 GCM | SHA384 | +| Key Exchange | Authentication | Encryption | Hash | +|:-------------|:---------------------------|:------------|:-------| +| DHE | RSA (2048-bit or 3072-bit) | AES 128 GCM | SHA256 | +| ECDHE | RSA (2048-bit or 3072-bit) | AES 128 GCM | SHA256 | +| DHE | RSA (2048-bit or 3072-bit) | AES 256 GCM | SHA384 | +| ECDHE | RSA (2048-bit or 3072-bit) | AES 256 GCM | SHA384 | +Only the first of the above cipher suites is required to be supported by all TLS 1.3 implementations (RFC 8446, Section 9.1). Each cipher suite includes a signature suite (the _Authentication_ and _Hash_ fields). -Adhering to RFC 7525 means that RSA (2048-bit or 3072-bit) with SHA256 or SHA384 is used to sign certificates. +Adherence to RFC 7525 means that RSA (2048-bit or 3072-bit) with SHA256 or SHA384 is used to sign certificates. Given that RFC 7525 is trusted, SHA256 and SHA384 _may_ be suitable choices for producing certificate identifiers, as discussed in Section 4. The above recommendations are _general_, in the sense that no particular assumptions are made about the setting in which the device employing the signature or cipher suite is located. @@ -795,6 +798,35 @@ The list is likely to be revised as more experience is gained related to the sec ## 6. TLS Authentication and Authorization +By default, the initiator of a given TLS connection, or _client_, validates the certificates of its peer, or _server_, but not vice versa. +In the context of Arrowhead, it will rarely, if ever, be relevant to only have one peer present its certificates. +For this reason, the `post_handshake_auth` extension (RFC 8446, Section 4.6.2) of TLS _must_ always be enabled, which forces both peers to present certificate chains that contain a root CA trusted by the other peer. +A server receiving a TLS _Client Hello_ message (RFC 8446, Section 4.1.2) without the `post_handshake_auth` extension specified _must_ abort the connection. +It _should_ send a `certificate_required` alert as part of the abortion procedure (RFC 8446, Section 6.2). +Use of the `post_handshake_auth` extension is referred to as _client-side authentication_ by many software libraries and applications. + +After completing the RFC 5280 validation procedure, the following must hold for each certificate in the chain presented by a given peer: + +1. At lest one `subject` Distinguished Name Qualifier (`DN`) must be present. +2. The value of the rightmost (i.e. least significant) `DN` must be equal to an Arrowhead certificate profile identifier specified in Section 2.1.6. +3. At least one `subject` Common Name (`CN`) must be present. +4. The value of the rightmost (i.e. least significant) `CN` must be a valid DNS label of between 1 and 62 DNS characters, as specified in Section 2.1.6. +5. If the certificate is at the bottom of the certificate chain, which means that it belongs to the peer, the _Subject Alternative Name_ extension must be present. +6. If the _Subject Alternative Name_ extension is present, it must identify the transport identity (i.e. IP address, DNS name, etc.) of the peer. See Section 2.1.9.4. +7. If the rightmost `DN` of a given certificate is equal to + 1. `on`, `de`, `sy` or `op`, its issuer must be a Local Cloud certificate, + 2. `lo`, its issuer must be an Organization certificate, or + 3. `or` or `ga`, its issuer must be a Master certificate. + +Given that the above points are satisfied, the certificate is considered as an Arrowhead certificate. +If a given Master certificate is not self-signed, any certificates above it do not have to be Arrowhead certificates, which means that they do not need to satisfy the above points. + +If the above points are not satisfied, the connection _must_ be immediately aborted. +An `access_denied` alert _should_ be sent as part of the abortion procedure. + +Peers _may_ use details extracted from this procedure as input to further authorization procedures. +An example of such a procedure could be to only allow operators part of the same cloud to connect to a the service provided by a certain system. + ## 7. DNS Support and its Security Implications ## 8. Subject Alternative Names and Device Mobility From c62fef6623b756019665bd067395f5ff3ac0a9ed Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Thu, 26 Aug 2021 19:55:52 +0200 Subject: [PATCH 34/36] Work on proposal.md --- proposal.md | 52 ++++++++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/proposal.md b/proposal.md index b03e26c..18c6e97 100644 --- a/proposal.md +++ b/proposal.md @@ -63,10 +63,10 @@ The standard is used to describe the structure of X.509 certificates, which _mus - __Object Identifier (OID)__: A hierarchical and universally unique identifier, useful for identifying parts of ASN.1 messages. - __Octet__: An 8-bit byte. -#### 1.2.5 TLS +#### 1.2.5 TLS and DTLS -_Transport Layer Security_ (TLS), an IETF (Internet Engineering Task-Force) standard for establishing secure connection over untrusted transports. -Used in tandem with X.509 to establish that the identities of any connecting parties can be authenticated. +_Transport Layer Security_ (TLS) and _Datagram Transport Layer Security_ (DTLS) are IETF (Internet Engineering Task-Force) standards for establishing secure connections over untrusted transports. +Can leverage X.509 to perform authentication. - __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a peer. - __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. The _authentication_ and _hash_ algorithms form a _signature suite_. @@ -796,29 +796,29 @@ The above list is _not_ to be considered as being exhaustive. Adhering to it is not a substitute for consulting independent and credible security experts. The list is likely to be revised as more experience is gained related to the security of Arrowhead installations. -## 6. TLS Authentication and Authorization - -By default, the initiator of a given TLS connection, or _client_, validates the certificates of its peer, or _server_, but not vice versa. -In the context of Arrowhead, it will rarely, if ever, be relevant to only have one peer present its certificates. -For this reason, the `post_handshake_auth` extension (RFC 8446, Section 4.6.2) of TLS _must_ always be enabled, which forces both peers to present certificate chains that contain a root CA trusted by the other peer. -A server receiving a TLS _Client Hello_ message (RFC 8446, Section 4.1.2) without the `post_handshake_auth` extension specified _must_ abort the connection. -It _should_ send a `certificate_required` alert as part of the abortion procedure (RFC 8446, Section 6.2). -Use of the `post_handshake_auth` extension is referred to as _client-side authentication_ by many software libraries and applications. - -After completing the RFC 5280 validation procedure, the following must hold for each certificate in the chain presented by a given peer: - -1. At lest one `subject` Distinguished Name Qualifier (`DN`) must be present. -2. The value of the rightmost (i.e. least significant) `DN` must be equal to an Arrowhead certificate profile identifier specified in Section 2.1.6. -3. At least one `subject` Common Name (`CN`) must be present. -4. The value of the rightmost (i.e. least significant) `CN` must be a valid DNS label of between 1 and 62 DNS characters, as specified in Section 2.1.6. -5. If the certificate is at the bottom of the certificate chain, which means that it belongs to the peer, the _Subject Alternative Name_ extension must be present. -6. If the _Subject Alternative Name_ extension is present, it must identify the transport identity (i.e. IP address, DNS name, etc.) of the peer. See Section 2.1.9.4. -7. If the rightmost `DN` of a given certificate is equal to - 1. `on`, `de`, `sy` or `op`, its issuer must be a Local Cloud certificate, - 2. `lo`, its issuer must be an Organization certificate, or - 3. `or` or `ga`, its issuer must be a Master certificate. - -Given that the above points are satisfied, the certificate is considered as an Arrowhead certificate. +## 6. TLS/DTLS Authentication and Authorization + +TODO: Finish this ... + +By default, the initiator of a TLS or DTLS session validates the certificate chain of its peer, but not vice versa. +In the context of Arrowhead, however, authentication _must_ always be mutual when Arrowhead-compliant peers communicate. +This is facilitated by using the `post_handshake_auth` extension (RFC 8446, Section 4.6.2), which requires each of the two peers to present certificate chains that contain a root CA trusted by the other peer. +More specifically, if a peer receives a _Client Hello_ message (RFC 8446, Section 4.1.2) without the `post_handshake_auth` extension specified, it _must_ abort the connection with a `certificate_required` alert (RFC 8446, Section 6.2). +Use of the `post_handshake_auth` extension is referred to as _client-side authentication_ by many software libraries and applications, as the initiator, or _client_, is also authenticated by the respondent, or _server_. + +If an Arrowhead Master certificate is the trust anchor of both peers, the authentication procedure is done at this point. +If, however, the Master certificate is an intermediate CA, the following steps must be executed to ensure that the peer is A + +1. Is at lest one `subject` Distinguished Name Qualifier (`DN`) present? +2. If (1), is the value of the rightmost (i.e. least significant) `DN` be equal to an Arrowhead certificate profile identifier specified in Section 2.1.6? +3. Is at least one `subject` Common Name (`CN`) present? +4. If (3), is the value of the rightmost (i.e. least significant) `CN` a valid DNS label of between 1 and 62 DNS characters, as specified in Section 2.1.6? +5. If the certificate is at the bottom of the certificate chain, which means that it belongs to the peer, is the _Subject Alternative Name_ extension present? +6. If (5), is the _Subject Alternative Name_ extension identifying the transport identity (i.e. IP address, DNS name, etc.) of the peer, as described in Section 2.1.9.4? + +If the above points are satisfied, the certificate is considered as an Arrowhead certificate, the profile of which is determined by the `DN` value. +The certificate at the bottom of the presented certificate chain _must_ be an Arrowhead certificate. + If a given Master certificate is not self-signed, any certificates above it do not have to be Arrowhead certificates, which means that they do not need to satisfy the above points. If the above points are not satisfied, the connection _must_ be immediately aborted. From af21b7679699a6dd81b7300aea41eed5e4a8f75d Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 3 Sep 2021 15:09:15 +0200 Subject: [PATCH 35/36] Work on proposal.md --- proposal.md | 94 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 57 insertions(+), 37 deletions(-) diff --git a/proposal.md b/proposal.md index 18c6e97..62379df 100644 --- a/proposal.md +++ b/proposal.md @@ -66,7 +66,7 @@ The standard is used to describe the structure of X.509 certificates, which _mus #### 1.2.5 TLS and DTLS _Transport Layer Security_ (TLS) and _Datagram Transport Layer Security_ (DTLS) are IETF (Internet Engineering Task-Force) standards for establishing secure connections over untrusted transports. -Can leverage X.509 to perform authentication. +Both can use X.509 to perform authentication when establishing secure connections. - __Authentication Algorithm__: An asymmetric, or _public key_, encryption algorithm used to establish a degree of confidence in the identity of a peer. - __Cipher Suite__: A four-part set consisting of a _key exchange_, _authentication_, _encryption_ and _hash_ algorithm. Such a suite must be agreed upon for a TLS connection to be possible to establish. The _authentication_ and _hash_ algorithms form a _signature suite_. @@ -445,7 +445,7 @@ Its use is _recommended_ for revoking and verifying the validity of On-Boarding, #### 2.1.9.6 Information Extensions The information extensions allows for various types of data sources or services to be associated with the certificate holder. -These extensions _should not_ be used. +These extensions _should not_ be used, unless required by a protocol relevant for the revocation of Master, Organization, Gate and Local Cloud certificates. Eclipse Arrowhead has its own provisions for metadata distribution and service management, via the _Service Registry_ system, _Gatekeeper_ system, and other. Those provisions _should_ be used. @@ -779,8 +779,8 @@ See Section 3 for details about what hash algorithms to use. Certificates must be created, distributed, replaced as they expire and, sometimes, revoked before they expire. If these tasks are handled without care, it can lead to serious security vulnerabilities. -To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing the certificate life-cycle within a local clouds. -We _recommend_ that the system be used, or a similarly capable replacement, for all Eclipse Arrowhead installations, whenever possible. +To help making this handling as rigorous as possible, the Eclipse Arrowhead project provides the _Certificate Authority_ system, which, through some other helper systems, provides an infrastructure for managing the certificate life-cycle within local clouds. +We _recommend_ that the system be used, or a similarly capable replacement, for all Eclipse Arrowhead installations. Generally, when certificate life-cycles are managed, we _recommend_ that the following be observed: @@ -796,46 +796,66 @@ The above list is _not_ to be considered as being exhaustive. Adhering to it is not a substitute for consulting independent and credible security experts. The list is likely to be revised as more experience is gained related to the security of Arrowhead installations. -## 6. TLS/DTLS Authentication and Authorization - -TODO: Finish this ... - -By default, the initiator of a TLS or DTLS session validates the certificate chain of its peer, but not vice versa. -In the context of Arrowhead, however, authentication _must_ always be mutual when Arrowhead-compliant peers communicate. -This is facilitated by using the `post_handshake_auth` extension (RFC 8446, Section 4.6.2), which requires each of the two peers to present certificate chains that contain a root CA trusted by the other peer. -More specifically, if a peer receives a _Client Hello_ message (RFC 8446, Section 4.1.2) without the `post_handshake_auth` extension specified, it _must_ abort the connection with a `certificate_required` alert (RFC 8446, Section 6.2). -Use of the `post_handshake_auth` extension is referred to as _client-side authentication_ by many software libraries and applications, as the initiator, or _client_, is also authenticated by the respondent, or _server_. - -If an Arrowhead Master certificate is the trust anchor of both peers, the authentication procedure is done at this point. -If, however, the Master certificate is an intermediate CA, the following steps must be executed to ensure that the peer is A - -1. Is at lest one `subject` Distinguished Name Qualifier (`DN`) present? -2. If (1), is the value of the rightmost (i.e. least significant) `DN` be equal to an Arrowhead certificate profile identifier specified in Section 2.1.6? -3. Is at least one `subject` Common Name (`CN`) present? -4. If (3), is the value of the rightmost (i.e. least significant) `CN` a valid DNS label of between 1 and 62 DNS characters, as specified in Section 2.1.6? -5. If the certificate is at the bottom of the certificate chain, which means that it belongs to the peer, is the _Subject Alternative Name_ extension present? -6. If (5), is the _Subject Alternative Name_ extension identifying the transport identity (i.e. IP address, DNS name, etc.) of the peer, as described in Section 2.1.9.4? +## 6. Authorizing Certificate Owners + +While no steps in addition to those in Section 6 of RFC 5280 are mandatory for certificate _validation_, there are additional details made available by our profiles that _should_ be used for _authorization_ when applicable. +These details are (A) profile identifiers and (B) issuer identities. +For example, if an Arrowhead system provides a service, it _may_ be relevant to ensure that any consumer of that service belongs to the same local cloud and is an operator. + +We _recommend_ that a procedure practically equivalent to the below algorithm, described in pseudo-code, is used when extracting certificate profile identifiers. +The input to the algorithm is an array containing a certificate chain `chain` of a given peer. +The certificate at index 0 of that array is owned by the peer in question, while the remaining certificates represent its issuance hierarchy, in order of issuance from least significant to most. + +```js +function getCertificateProfileIdentifier(chain) { + if (chain.length == 0) { throw "empty chain"; } + + let dnq = getDNQualifier(chain[0]); + switch (dnq) { + case "ma": + break; + case "or": case "ga": + requireProfileSequence(chain[1..], ["ma"]); break; + case "lo": + requireProfileSequence(chain[1..], ["or", "ma"]); break; + case "on": case "de": case "sy": case "op": + requireProfileSequence(chain[1..], ["lo", "or", "ma"]); break; + default: + throw "unexpected DNQualifier"; + } + return dnq; +} -If the above points are satisfied, the certificate is considered as an Arrowhead certificate, the profile of which is determined by the `DN` value. -The certificate at the bottom of the presented certificate chain _must_ be an Arrowhead certificate. +function requireProfileSequence(chain, identifiers) { + if (identifiers.length == 0) { return; } + if (chain.length == 0) { throw "expected additional certificate(s)"; } -If a given Master certificate is not self-signed, any certificates above it do not have to be Arrowhead certificates, which means that they do not need to satisfy the above points. + if (getDNQualifier(chain[0]) != identifiers[0]) { + throw "unexpected certificate profile"; + } -If the above points are not satisfied, the connection _must_ be immediately aborted. -An `access_denied` alert _should_ be sent as part of the abortion procedure. + requireProfileSequence(chain[1..], identifiers[1..]); +} +``` -Peers _may_ use details extracted from this procedure as input to further authorization procedures. -An example of such a procedure could be to only allow operators part of the same cloud to connect to a the service provided by a certain system. +The `getDNQualifier` function is assumed to extract the `subject` `DN` field, described in Section 2.1.6, of a given certificate. +If several such fields is present in a given certificate, the rightmost (i.e. least significant) must be returned by the function. +The `[1..]` notation is used to describe an array being "sliced" such that a new array is produced containing all but the first element of the original array. +The algorithm asserts that any extracted identifier appears at the expected hierarchical level, apart from extracting the identifier itself. -## 7. DNS Support and its Security Implications +Testing elements of an issuance hierarchy could be performed by comparing certificate DER representations byte by byte, or by comparing their DER hashes. +The following pseudo-code describes how a service provider could assert that a given peer is a system belonging to a certain local cloud: -## 8. Subject Alternative Names and Device Mobility +```js +if (getCertificateProfileIdentifier(peer.chain) != "sy" || hash(peer.chain[1]) != hashOfRelevantLocalCloudCertificate) { + throw "unauthorized"; +} +``` -Devices and systems are assumed not to change IP addresses or DNS names during their lifetimes, as these are recorded in their certificates. -This makes it a bit more challenging when devices need to move between networks and, as a consequence, may be assigned new IP addresses. -However, as mobility at a scale that makes this setup a problem is currently deemed of marginal utility, no provisions are given for it directly. -It could be working around by using proxies, negotiating a new certificate every network handover, recording all relevant IP addresses in advance in each certificate, and so on. +Note that if either of the secure transports TLS or DTLS is used by a given Arrowhead peer, the `post_handshake_auth` extension (RFC 8446, Section 4.6.2), must be required in order for both peers of a connection to provide and validate certificates. +The extension _should_ always be required when Arrowhead systems communicate. +Use of the `post_handshake_auth` extension is referred to as _client authentication_ by many software libraries and applications, as the initiating peer, or _client_, is also authenticated by the responding peer, or _server_. ## References -TODO \ No newline at end of file +(Will be added in the formatted (LaTeX) version of this document.) \ No newline at end of file From 24f8e0cf45a5976bc3d99a096b4802770ed49d99 Mon Sep 17 00:00:00 2001 From: Emanuel Palm Date: Fri, 3 Sep 2021 15:39:53 +0200 Subject: [PATCH 36/36] Work on proposal.md --- proposal.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/proposal.md b/proposal.md index 62379df..ab1523a 100644 --- a/proposal.md +++ b/proposal.md @@ -6,11 +6,20 @@ This document specifies how X.509 certificates are to be configured, issued and ## 1. Introduction -TODO +In this document, we describe how X.509 certificates must be configured if used in conjunction with Eclipse Arrowhead. +X.509 is a certificate standard produced by the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) and is famously used by the TLS and DTLS protocols, the former of which is used to establish secure connections on the World Wide Web. +In brief, an X.509 certificate represents the identity of its owner. +It records required inputs to a secure key exchange algorithm, as well as how the identity it represents is endorsed by a hierarchy of issuers. +In the context of Eclipse Arrowhead, X.509 certificates are used to manage what IoT devices, and other entities, are to be trusted and what cryptographic algorithms are to be used to establish their identities. + +The rest of this document is organized as follows. +This section continues by listing key terminology and outlining some linguistic conventions. +Section 2 outlines the X.509 certificate format and the 8 core Arrowhead X.509 profiles. +Sections 3, 4, 5 and 6 consider secure algorithm inputs, certificate identification, certificate life-cycle management, and using certificates as input to authorization procedures, respectively. ### 1.1 Relation to the IETF RFC 5280 X.509 Profile -All certificate profiles specified in this document are _required_ to be strict subsets of the RFC 5280 X.509 profile, which regulates the use of X.509 certificates on the World Wide Web. +All certificate profiles specified in this document are _required_ to be strict subsets of the RFC 5280 X.509 profile of the Internet Engineering Task Force (IETF). ### 1.2 Significant Terminology