Topic S - Certificate transparency #584
Replies: 7 comments 9 replies
-
|
What is absolutely critical is to have Qualified Unlinkable certificates both both for access control and for unlinkable issuing of credentials and data portability. The main problem with ARF as-is is the surveillance-by-design PID document that force all issuance to be bed based on linked identification. |
Beta Was this translation helpful? Give feedback.
-
The requirement to log access certificates in a CT log is good, but the ARF should not require the use of RFC 9162 ("version 2.0") logs. I'm not aware of any current or planned deployments of RFC 9162 logs. The WebPKI is currently transitioning from RFC 6962 ("version 1") logs to Static CT logs [1,2,3]. The requirements laid out in the ARF should permit the development of standards based on Static CT and other emerging technologies such as Merkle Tree Certificates. |
Beta Was this translation helpful? Give feedback.
-
|
That requirement is from the Commission Implementing Regulation (EU) 2025/848:
(Still worth discussing, though.) |
Beta Was this translation helpful? Give feedback.
-
|
I implement transparency logs, and I agree with @jschanck that requiring RFC 9162 logs will be tricky. To my knowledge there are no production-ready implementations of logs that implement this spec. It would be far easier to adopt Static CT, or as a fallback the older RFC 6962; both of these specs have a choice of production-tested implementations available in open source. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see a requirement for the publication of a list of CT logs that providers of wallet-relying party access certificates may use. A CT log is a trust anchor for signed certificate timestamps, signed tree heads, and related documents. The allowed CT log trust anchors will need to be distributed to many parties, including individual wallet instances, so they will need to be published in something like a trusted list. There should also be some discussion here on governance of / policy for this CT log list (how logs come to be included, when they can be removed, etc). The existing policies for WebPKI CT log lists from browser vendors can serve as a guide. It's not clear to me who should be responsible for enforcing the CT log list policy in the EUDI case. |
Beta Was this translation helpful? Give feedback.
-
Existing WebPKI CT logs should not be used for wallet-relying party access certificates. (If the suggestion was that log operators should create new logs for wallet-relying party access certificates, then most of what I've written below can be ignored). I imagine that most CT log monitors are interested in exactly one type of certificate. That is, I think there are monitors who are interested in WebPKI certificates, and I think are monitors who are interested in wallet-relying party access certificates, and I think there is little overlap between these two groups. The cost of operating an RFC 6962, 9162, or Static CT log scales with the size of the log and with the number of parties that wish to monitor the log. So CT log operators will want to run separate logs for different types of certificates: this reduces the amount of data that they need to serve to single-certificate-type monitors and decreases their overall costs. On a more technical note, different "types" of certificates are distinguished by the "Extended Key Usage" extension. Existing WebPKI CT logs may reject a certificate that does not have the |
Beta Was this translation helpful? Give feedback.
-
Oh why not? It's the wallet-relying party who asked for validation of the user's ID, right? A wallet-relying party access certificate would dictate what information can be requested by the wallet-relying party, right? If used online, the wallet-relying party must be uniquely identified to the user agent, maybe by domain name, but even better by the actual key in their TLS certificate.
It's clear there are quite different types of wallet-relying party access certificates, so yes you might want to audit the list who can ask for PII vs the list who can ask for over 18. Yet, we should expect far fewer wallet-relying party access certificates than TLS certificates, because each wallet-relying party access certificates requires a TLS certificate. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, no, that's the wallet relying-part registration certificate (see CIR 2025/848). But that's independent of the CT log discussion.
Correct
Not sure. But as you say, this is only the case for online (as in "web-based") relying parties, and not for "proximity" relying parties (where you present your wallet on a phone via, e.g., Bluetooth, to a RP in physical proximity). This is far away from any Web and hence WebPKI. I guess that's part of the objection.
For this, you would audit/monitor the RP register (see, e.g., CIR 2025/848).
How so? |
Beta Was this translation helpful? Give feedback.
-
|
I'll rephrase, if you use the EU ID wallet online, then you need to identify the other side, not merely the RP, but the interface surounding whatever the RP does. If not, then you'll have cross-site identiy theft attacks, say by forwarding requests from legitimate RPs. An RP in physical proximity seems quite different of course. |
Beta Was this translation helpful? Give feedback.
-
Right, and that's why there should be (smaller, cheaper to operate, and easier to monitor) CT logs that are used only for wallet-relying party access certificates.
Absolutely. There are details on how that works when OpenID4VP is used through the Digital Credentials API here. |
Beta Was this translation helpful? Give feedback.
-
|
I wholeheartedly agree with @jschanck in the original comment that "Existing WebPKI CT logs should not be used for wallet-relying party access certificates.". These CT logs are intended to be used for Web PKI certificates only. Other x509 certs are not the intended use case, and logs may reject them. For example, this CT log implementations allows the log to be configured to accept only certs with specific Extended Key Usages (EKUs): https://github.com/google/certificate-transparency-go/blob/master/trillian/ctfe/configpb/config.proto#L87. In the current version of the document, the next paragraph is "Alternatively, the European Commission could establish its own CT log infrastructure", and I strongly encourage this direction in the design. |
Beta Was this translation helpful? Give feedback.
-
An SCT is a promise that a log will contain an entry for a certificate in the (near) future. It is not, in and of itself, evidence that a log entry has been created. The use of SCTs in the WebPKI is a compromise position that was reached to balance the need for CT against the expectation of immediate issuance. The ARF should leave room for technical standards with slow issuance (e.g. several minutes delay between when a certificate is requested and when it is issued). Technical standards with slow issuance give CT logs enough time to produce cryptographic evidence of the creation of a log entry, and they give CAs enough time to embed this evidence in certificates. The ARF should leave room for technical standards that require access certificates to include strong evidence of correct logging, e.g. an inclusion proof to a signed tree head, or (better) an inclusion proof to a signed tree head with one or more witness signatures. |
Beta Was this translation helpful? Give feedback.
-
|
There are a small variety of transparency log implementations that exist and this format could be utilized and ran possibly by the existing EU PKI that's set up with Qualified Trusted Service Providers. I don't think the transparency requirement is inappropriate but the strict technical mandates around RFC 9162 and SCT are. I agree with the above around SCTs needing strong evidence and flexibility with with log implementation.
Definitely don't think it should be done directly due to privacy risk, however paired with the SCT "slowed" checks, maybe this does not need to be a real time check with each access request? I know I am getting into the realm of caching but since this isn't the same situation as a browser needing to operate on a higher scale of serving best case, safe access to websites at all times, I am wondering what else can be made more flexible here. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for bringing up this observation that directly querying the log for a given cert leaks information. Removing SCTs from the design would allow for a stronger form of log inclusion to be circulated instead: offline inclusion proofs. This idea has been used in a number of transparency solutions, and is being formalized as a spec here: C2SP/C2SP#181. As observed in the spec, offline inclusion proofs can simply be considered a detached digital signature. The TL; DR of it is that providing {Log Checkpoint (ideally witnessed), Leaf Index, Inclusion Proof} along with the certificate logged in the leaf allows anyone to verify inclusion in the log while offline. This makes it more useful, with stronger guarantees, and more privacy preserving. |
Beta Was this translation helpful? Give feedback.
-
|
Moving towards a stronger yet flexible way of log inclusion that veers away from real-time, direct queries of the log is definitely a better path forward. The lessons from running these logs should be carried over and not just the structure. |
Beta Was this translation helpful? Give feedback.
-
|
@phin10, since there is currently an open consultation regarding 2025/848, the CIR where CT for RP Access Certs is mandated, do you know of any discussions from the ARF regarding this? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description
Requirement Reg_13 in ARF 1.4.0 requires support for Certificate Transparency for Access certificates. We received comments that this requirement is not appropriate. This needs to be discussed.
Ppublication discussion paper
19 September 2025
Link to discussion paper
Link
Discussion close
Three weeks later.
Beta Was this translation helpful? Give feedback.
All reactions