1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
---
title: Incidence
description: The incidence section of Fort's configuration file is a means to modify its behavior upon encountering profile violations that, from experience, are often overlooked.
---
# {{ page.title }}
## Index
1. [Introduction](#introduction)
2. [`incidences` definition](#incidences-definition)
3. [Incidence types](#incidence-types)
1. [Signed Object's hash algorithm has NULL object as parameters](#signed-objects-hash-algorithm-has-null-object-as-parameters)
2. [Object isn't DER encoded](#object-isnt-der-encoded)
3. [File listed at manifest doesn't exist](#file-listed-at-manifest-doesnt-exist)
4. [File hash listed at manifest doesn't match the actual file hash](#file-hash-listed-at-manifest-doesnt-match-the-actual-file-hash)
5. [Manifest is stale](#manifest-is-stale)
6. [CRL is stale](#crl-is-stale)
## Introduction
The RPKI RFCs define fairly strict profiles for RPKI objects, and are unequivocal in stating that incorrectly-formed objects are supposed to be rejected by Relying Party validation. In practice, however, this does not prevent a significant amount of legitimate Certificate Authorities from issuing incorrect objects.
The `incidence` section of FORT's configuration file is a means to modify its behavior upon encountering profile violations that, from experience, are often overlooked.
## `incidences` definition
`incidences` is a JSON array that contains (anonymous) incidence elements. Here's an example:
```
"incidences": [
{
"name": "incid-hashalg-has-params",
"action": "warn"
}
]
```
`name` is the identifier of an incidence. It is case-sensitive and developer-defined. It states the ID of the particular error condition that will be handled by the remaining field.
`action` is an enumeration that states the outcome of a violation of the corresponding incidence. It can take one of three values:
1. `error`: Print error message in `error` log level, fail validation of the offending object (and all of its children).
2. `warn`: Print error message in `warning` log level, continue validation as if nothing happened.
3. `ignore`: Do not print error message, continue validation as if nothing happened.
Some incidences are `ignore`d by default, because they stem from bad practices (which are nonetheless likely harmless) in the global RPKI repositories. If a strict behavior is desired, then the corresponding incidence `action` should be upgraded.
## Incidence types
Presently, there are a few incidences defined. This list might evolve further over time, depending on the state of the global RPKI and user demand.
### Signed Object's hash algorithm has NULL object as parameters
- **Name:** `incid-hashalg-has-params`
- **Default action:** `ignore`
[RFC 6488](https://tools.ietf.org/html/rfc6488) (RPKI Signed Objects) defers digest algorithm specification to RFC 6485:
```
The digestAlgorithms set contains the OIDs of the digest algorithm(s)
used in signing the encapsulated content. This set MUST contain
exactly one digest algorithm OID, and the OID MUST be selected from
those specified in [RFC6485].
```
[6485](https://tools.ietf.org/html/rfc6485) has been obsoleted by [7935](https://tools.ietf.org/html/rfc7935), which states the following:
```
The object identifier and
parameters for SHA-256 (as defined in [RFC5754]) MUST be used for the
SignedData digestAlgorithms field and the SignerInfo digestAlgorithm
field.
```
[RFC 5754](https://tools.ietf.org/html/rfc5754):
```
There are two possible encodings for the AlgorithmIdentifier
parameters field associated with these object identifiers. (...)
some implementations encode parameters as a NULL element
while others omit them entirely. The correct encoding is to omit the
parameters field;
```
As of 2020-07-14, many signed objects in the global RPKI break this rule.
If not `ignore`d, FORT will report this incidence with the following error message at the validation log:
```
<log level>: <offending file name>: The hash algorithm of the '<object>' has a NULL object as parameters
```
This only applies to digest parameters that have been defined as NULL objects; any other type of non-absent digest parameters will yield a different error message, and will therefore not be silenced.
### Object isn't DER encoded
- **Name:** `incid-obj-not-der-encoded`
- **Default action:** `ignore`
[RFC 6488](https://tools.ietf.org/html/rfc6488) mandates that all signed objects must be DER-encoded (see [section 3](https://tools.ietf.org/html/rfc6488#section-3)):
```
l. The signed object is DER encoded.
```
Altough this is mandatory, quite a few signed objects in the global RPKI ignore this rule and are simply BER-encoded.
If not `ignore`d, FORT will report this incidence with the following error message at the validation log:
```
<log level>: <offending file name>: '<object>' isn't DER encoded
```
### File listed at manifest doesn't exist
- **Name:** `incid-file-at-mft-not-found`
- **Default action:** `error`
[RFC 6486 section 6.1](https://tools.ietf.org/html/rfc6486#section-6.1) considers this scenario:
```
2. {..} If there exist files at the publication point that do not appear
on any manifest, or files listed in a manifest that do not appear
at the publication point, then see Section 6.5, but still continue
with the following test.
```
If there's a missing file, it could be a publisher error or even an attack against the publication point (see [section 6.5](https://tools.ietf.org/html/rfc6486#section-6.5)).
By default, FORT validator will handle this as an error, thus discarding the manifest file.
When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
```
<log level>: <manifest file name>: File '<file name>' listed at manifest doesn't exist.
```
### File hash listed at manifest doesn't match the actual file hash
- **Name:** `incid-file-at-mft-hash-not-match`
- **Default action:** `error`
[RFC 6486 section 6.1](https://tools.ietf.org/html/rfc6486#section-6.1) considers this scenario:
```
4. {..} If the computed hash value of a file listed on the manifest does
not match the hash value contained in the manifest, then see
Section 6.6.
```
It's up to a local policy to discard these files (and the rest of the manifest files) or trust in them (see [section 6.6](https://tools.ietf.org/html/rfc6486#section-6.6)).
By default, FORT validator will discard such files and the manifest as well.
When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
```
<log level>: <manifest file name>: File '<file name>' does not match its manifest hash.
```
### Manifest is stale
- **Name:** `incid-mft-stale`
- **Default action:** `error`
[RFC 6486 section 6.1](https://tools.ietf.org/html/rfc6486#section-6.1) considers this scenario:
```
3. Check that the current time (translated to UTC) is between
thisUpdate and nextUpdate.
If the current time does not lie within this interval, then see
Section 6.4 {..}
```
And citing [section 6.4](https://tools.ietf.org/html/rfc6486#section-6.4):
```
A manifest is considered stale if the current time is after the
nextUpdate time for the manifest. {..}
All signed objects at the publication point issued by the entity that
has published the stale manifest, and all descendant signed objects
that are validated using a certificate issued by the entity that has
published the stale manifest at this publication point, SHOULD be
viewed as somewhat suspect, but MAY be used by the RP as per local
policy.
```
This 'local policy' is the equivalent to the incidence `incid-mft-stale`.
By default, FORT validator will discard a stale manifest and all of its listed elements.
When the incidence is not `ignore`d, FORT will report it with the following message at the validation log:
```
<log level>: <manifest file name>: Manifest is stale. (nextUpdate: <human readable date> )
```
### CRL is stale
- **Name:** `incid-crl-stale`
- **Default action:** `error`
The RFC's aren't clear about stale CRLs; but as strict (or pedantic) as FORT is, a stale CRL isn't trusted by default. A stale CRL is the one where its 'nextUpdate' is in the past.
The "cost" of stop using a stale CRL, is that all of the related CA childs will be discarded as well.
There's a whole discussion on this subject at SIDROPS WG (see the mail archive for ["[Sidrops] what to do when the CRL is hosed?"](https://mailarchive.ietf.org/arch/msg/sidrops/tCybZO7YvXbdVm5pA7DbHEnuKEc/); so, until a concensus is reached on the matter, the RP operator can configure the incidence `incid-crl-stale` to decide how to treat this CRLs.
When the incidence is not `ignore`d, FORT will report it with the following message at the validation log (note that the CRL is validated as part of the manifest validation):
```
<log level>: <manifest file name>: CRL is stale/expired
```
|
