You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<td><ahref="p-secure-cryptographic-interface-between-the-Wallet-Instance-and-WSCA/">Secure Cryptographic Interface between the Wallet Instance and the WSCA</a></td>
Copy file name to clipboardExpand all lines: 2.7.1/discussion-topics/s-certificate-transparancy/index.html
+22-15Lines changed: 22 additions & 15 deletions
Original file line number
Diff line number
Diff line change
@@ -429,7 +429,7 @@
429
429
430
430
431
431
432
-
<p>Version 0.5, updated 8 October 2025</p>
432
+
<p>Version 1.0, updated 6 November 2025</p>
433
433
<p><ahref="https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/584">Link to GitHub discussion</a></p>
434
434
<h1id="topic-s-certificate-transparency">Topic S - Certificate Transparency</h1>
<p>A CA issuing access certificates SHALL register these in a CT log according to
482
482
RFC 9162. Examples of CT log providers are Google and Cloudflare for SSL/TLS
483
-
certificates issued for a domain or subdomain.</p>
483
+
certificates issued for a domain or subdomain. Currently no CT log providers are available in Europe. How to address this situation is out of scope of the ARF.</p>
484
+
<p>CT logs are used to ensure accuracy of issued access certificates with two or more log providers. This does not mean that the RP is registered or published twice. It only means that there is way to detect access certificates that were issued in error or fraudulently.</p>
485
+
<p>Trust provided by CT logs is limited to the issuance of access certificates. They are two or more sources of truth stating who an access certificate has been issued to.</p>
<p>Certificate Transparency (CT) is an open framework designed to improve the
486
488
security and accountability of the Public Key Infrastructure (PKI) used on the
@@ -551,9 +553,8 @@ <h4 id="331-eu-ct-log-infrastructure">3.3.1 EU CT log infrastructure</h4>
551
553
append-only, and that no unauthorized modifications or omissions go unnoticed.
552
554
Finally, drawing from the Web PKI best practice, it is important that
553
555
<strong>each certificate be registered in at least two independent CT logs</strong>. </p>
554
-
<p>It is assumed that the new European CT log infrastructure will define what
555
-
version of RFC 9162 and other implementation requirements such as the number
556
-
of CT logs a CA issuing access certificates shall register with is defined.</p>
556
+
<p>It is assumed that the new European CT log infrastructure will define
557
+
which standard to use, version of RFC 9162 or RFC 6962, and other implementation requirements such as the number of CT logs a CA issuing access certificates shall register with is defined.</p>
557
558
<h4id="332-ct-log-usage">3.3.2 CT log usage</h4>
558
559
<p>In the Web PKI, browsers do not directly interact with Certificate Transparency
559
560
(CT) logs to verify the inclusion of a certificate. Instead, they <strong>trust the
for detecting new domains (see for example, Kondracki et al. "Uninvited Guests:
578
579
Analyzing the Identity and Behavior of Certificate Transparency Bots", in Usenix
579
580
Security, 2022)</p>
580
-
<p>However, this is not expected to be case for CT logs for access certificates,
581
+
<p>However, this is not expected to be the case for CT logs for access certificates,
581
582
as the list of access certificates is already public. Collating all access certificates in one or more CT logs does not seem to pose any threat as this information is already publicly available.</p>
<p>It is important to recognise that <strong>Certificate Transparency (CT) logs do
@@ -613,39 +614,41 @@ <h3 id="41-possible-hlrs">4.1 Possible HLRs</h3>
613
614
<tbody>
614
615
<tr>
615
616
<td>CT_01</td>
616
-
<td>A CA issuing access certificates SHALL register these in a CT log according to RFC 9162, if such a log is available.</td>
617
+
<td>An Access CA issuing access certificates SHALL register these in a CT log according to RFC 9162, if such a log is available for access certificates.</td>
617
618
</tr>
618
619
<tr>
619
620
<td>CT_02</td>
620
-
<td>A CA issuing access certificates SHALL include a description in its CPS how all access certificates are logged according to RFC 9162</td>
621
+
<td>An Access CA issuing access certificates SHALL describe in its CPS how it logs all access certificates.</td>
621
622
</tr>
622
623
<tr>
623
624
<td>CT_03</td>
624
-
<td>In case a CT log provider is available, the Access CA's SHALL act as monitors in the CT eco-system</td>
625
+
<td>In case a CT log provider for access certificates is available, all Access CAs SHALL act as monitors in the CT ecosystem. Access CAs SHOULD still monitor the CT logs in situations of temporary unavailability.</td>
625
626
</tr>
626
627
<tr>
627
628
<td>CT_04</td>
628
-
<td>The issuing CA SHALL include at least one Signed Certificate Timestamp (SCT) in the certificate</td>
629
+
<td>An Access CA SHALL include at least one Signed Certificate Timestamp (SCT) in each access certificate.</td>
629
630
</tr>
630
631
<tr>
631
632
<td>CT_05</td>
632
-
<td>The Wallet Unit SHALL check that the access certificate includes at least one Signed Certificate Timestamp (SCT)</td>
633
+
<td>When verifying an access certificate during PID or attestation issuance or presentation, a Wallet Unit SHALL also verify that the access certificate includes at least one valid Signed Certificate Timestamp (SCT).</td>
633
634
</tr>
634
635
<tr>
635
636
<td>CT_06</td>
636
-
<td>A Wallet Unit SHALL not communicate with a RP which access certificate does not include a SCT</td>
637
+
<td>If an access certificate does not include a valid SCT, a Wallet Unit SHALL handle this as a failure or Relying Party authentication, in compliance with all requirements in [<ahref="#a234-topic-6---relying-party-authentication-and-user-approval">Topic 6</a>] and in particular requirement RPI_06a.</td>
637
638
</tr>
638
639
</tbody>
639
640
</table>
640
641
<p>The HLRs should address:
641
642
1. How the certificate verifier performs checks against the CT log? Directly or via a fraud detection system?
642
643
2. What checks that should be performed and what constitutes a malicious entry?
643
644
3. What protocols that should be offered by a fraud detection system to all certificate verifiers?</p>
644
-
<h3id="42-version-of-rfc-9162-in-cir-eu-2025848">4.2 Version of RFC 9162 in CIR (EU) 2025/848</h3>
645
-
<p>The CIR clearly states that version 2 of RFC 9162 shall be used. From comments received it seems that the previous version is implemented and used. As version 2 includes substantial improvements and the Commission might be developing a European CT log infrastructure it should be a task for this initiative to decide which version to use. Consideration of which version to use is dependent on if existing services (version 1) from Cloudflare and Google are to be used.</p>
645
+
<h3id="42-rfc-9162-in-cir-eu-2025848">4.2 RFC 9162 in CIR (EU) 2025/848</h3>
646
+
<p>The CIR clearly states that RFC 9162 shall be used. From comments received it seems that the previous standard (RFC 6962) is implemented and used. As RFC 9162 includes substantial improvements and the Commission might be developing a European CT log infrastructure it should be a task for this initiative to decide which standard
647
+
to use. Consideration of which version to use is dependent on if existing services from Cloudflare and Google are to be used.</p>
<p>It is planned to introduce a new section in the ARF on Certificate Transparency. This new section will describe aspects of CA’s issuing access certificates.</p>
648
650
<p>In addition to these planned changes, further changes on this subject will follow the outcome of the discussion.</p>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&size=40){kind=avatar}
0 commit comments