View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008957 | 10000-012: Discovery | Spec | public | 2023-05-11 05:39 | 2024-04-09 16:57 |
| Reporter | Martin Regen | Assigned To | Randy Armstrong | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.04 | ||||
| Fixed in Version | 1.05.04 RC1 | ||||
| Summary | 0008957: Allow CRL in certificate chains | ||||
| Description | https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2.6 describes that "All OPC UA applications shall accept partial or complete chains in any field that contains a DER encoded Certificate." However, it often happens that a certificate chain is used with intermediate and root CA for which no CRL is available in the cert stores yet. In such a case the validator/application must disable revocation in this case because otherwise the validation does not pass. In fact the .NET Standard cert validator implicitly disables revocation check for certificates sent with the chain. Now an attacker might be able to use this weakness to use a revoked intermediate/root to connect to an application which assumes it cannot validate the CRL of the issuer certs. As a solution it should be allowed to include CRL in the certificate chains where required. They follow they same encoding rules and can be easily skipped if the application doesn't recognize the CRL in the byte blob. Some IOP testing may be necessary. In addition allowing the CRL would also solve a use case when a GDS Push or Pull was just being finished and a signed application certificate was issued but the application has not received a trust list / issuer list update before the update- of the certificate. | ||||
| Tags | No tags attached. | ||||
| Commit Version | 1.05.04 RC | ||||
| Fix Due Date | |||||
|
|
Aside from the backwards-compatibility issues this might be present - is this safe? Imagine that an intermediate certificate gets "owned" and attacker now controls its private key. An admin might revoke a certificate and add it to this CRL. If this CRL is configured by the admin on the server then this all works fine. But you're suggesting that we start trusting the input of a potential attacker, who now owns the intermediate cert in this scenario, and can provide an empty CRL instead. |
|
|
Need a section in Part 12 on the chicken and egg problem when it comes to trusting the GDS. Discuss different ways to configure a server with a CRL out of band. |
|
|
Before a Client can provide any secrets associated with credentials to a CertificateManager it needs to know that it can trust the CertificateManager. This can be done by an administrator that, out-of-band, adds the CertificateManager to the Client TrustList. If this is not possible, the CertificateManager needs to be pre-configured with information about the Client Certificate that allows the CertificateManager to know that it can request Certificates or the Client uses credentials, such as a X509IdentityToken, that do not provide secrets to CertificateManager. Clients using Pull Management shall not allow users to provide secrets to a CertificateManager if it connects to an untrusted CertificateManager. |
|
|
Agreed to changes edited in web meeting. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-05-11 05:39 | Martin Regen | New Issue | |
| 2023-05-11 05:43 | Martin Regen | Description Updated | |
| 2023-05-11 05:46 | Martin Regen | Description Updated | |
| 2023-05-17 13:51 | Kevin Herron (Inductive Automation) | Note Added: 0019395 | |
| 2023-05-17 15:30 | Randy Armstrong | Note Added: 0019397 | |
| 2023-05-17 15:30 | Randy Armstrong | Project | 10000-006: Mappings => 10000-012: Discovery |
| 2023-05-30 18:26 | Jim Luth | Target Version | 1.05.03 RC1 => |
| 2023-06-06 15:17 | Jim Luth | Assigned To | => Randy Armstrong |
| 2023-06-06 15:17 | Jim Luth | Status | new => assigned |
| 2024-03-17 08:38 | Randy Armstrong | Status | assigned => resolved |
| 2024-03-17 08:38 | Randy Armstrong | Resolution | open => fixed |
| 2024-03-17 08:38 | Randy Armstrong | Fixed in Version | => 1.05.04 RC1 |
| 2024-03-17 08:38 | Randy Armstrong | Note Added: 0020912 | |
| 2024-04-09 16:57 | Jim Luth | Status | resolved => closed |
| 2024-04-09 16:57 | Jim Luth | Commit Version | => 1.05.04 RC |
| 2024-04-09 16:57 | Jim Luth | Note Added: 0021101 |
