| I have one observation which may or may not be relevant.
When the US Government started soliciting for software attestations, these had to be signed by an organization’s chief executive, or their authorized representative, and they carry the potential for *criminal penalties* - not just economic penalties. In my opinion, this puts them into a very different risk category than a regulatory requirement which might carry a fine, or even under the revised PLD, a further punitive (but still financial) penalty. I haven’t heard anything about that in reference to the CRA, but I still have that association with the word “attestation”, (sorry, I don’t speak German!). On Oct 28, 2025, at 4:11 PM, Alistair Woodman via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Tobie,
very useful set of pointers and thoughts. I will pick up on the first point in the first 2 paragraphs.
[From Tobie] FWIW, the German text uses the word Bescheinigung, not Beglaubigung. My understanding is that Bescheinigung confirms that something is true or has occured (e.g. passing an exam), while Beglaubigung confirms the authenticity of something (e.g a certified copy).
This I think is a very useful point of semantics that I think we need to get our heads around. Imo (as a relatively competent German speaker), There is some overlap in common usage, such that we ought to focus attention on the differences.
1) Bescheinigung (Certificate) is something that I expect to come from a Regulated Authority / Entity and be given to (less entrusted) people / entities. Thinking of Driving Licenses, Marriage Certificate, etc
2) Beglaubigung (Certification, Affidavit, Notarization) is something that I expect when some (less trusted) person or entity wants to formally declare something or some item to be original or an accurate copy or a sworn statement that binds the thing to the person / entity attesting to it. Such statements are made to a (more trusted or entrusted) Notary.
Since I expect ‘CRA Attestations’ to happen very offen, maybe > 100K a day at OS repo scale, I cannot see one central entity doing this ‘at quality’. My assumption (present mental model) is that a highly decentralized model is more appropriate, where individual maintainers and small projects can make statements (such as: pull request X fixes issue Y and W says so at time Z) about what they have done and maybe that the Stewards act as Notaries to such statements. While Stewards might make more complex statements after full CI/CD testing etc, that might start to ‘smell’ like Certificates, I still think Affidavit is the best model, from Wikipedia: ( https://en.wikipedia.org/wiki/Affidavit)
An affidavit is typically defined as a written declaration or statement that is sworn or affirmed before a person who has authority to administer an oath. There is no general defined form for an affidavit, although for some proceedings an affidavit must satisfy legal or statutory requirements in order to be considered.[1] An affidavit may include,
- a commencement which identifies the affiant;
- an attestation clause, usually a jurat, at the end certifying that the affiant made the statement under oath on the specified date;
- signatures of the affiant and person who administered the oath.
In some cases, an introductory clause, called a preamble, is added attesting that the affiant personally appeared before the authenticating authority. An affidavit may also recite that the statement it records was made under penalty of perjury.
Thoughts ?
/a On Oct 28, 2025, at 16:40, Tobie Langel <tobie@xxxxxxxxxxxxxx> wrote:
Elizabeth, greetings and comments inline. In my understanding, an attestation is a contract between two entities: the manufacturer, and the attestation provider.
The general sense of the word ‘Attestation’ in english (and ‘Beglaubigung’ in German) is *not* of a contract, but of a ‘statement under oath’. I.e. the Attestor makes an Affidavit (Statement under oath, with a jeopardy of either perjury or negligence) to an entity with civil or legal authority (Notary, Judge, Police, Priest etc). WRT the CRA, the details of process are still TBD, but my assumption is that the actual Attestation is *not* a contract, but that could be used as part of a contract or process or supply-chain verification thingy to.
FWIW, the German text uses the word Bescheinigung, not Beglaubigung. My understanding is that Bescheinigung confirms that something is true or has occured (e.g. passing an exam), while Beglaubigung confirms the authenticity of something (e.g a certified copy).
The challenge is to adapt such a model (which works by giving manufacturers the ability to demand higher prices by demonstrating that they meet certain specific security requirements) to a completely different economic model, while making sure not to turn maintainers or stewards into manufacturers in the process (which would entirely defeat the purpose).
For example, consider Article 33(1) of the EUCC Certification Scheme delegated act which states that "[t]he holder of an EUCC certificate shall establish and maintain all necessary vulnerability management procedures in accordance with […]". There are similar requirements in Annex I of the CRA, so that's an interesting example to consider.
Imagine adapting something like this to the economic model of open source with the hope of getting similar security outcomes for the end-product.
We can't place that requirement on the project. That wouldn't make sense, as the CRA clearly puts the obligations on the manufacturer. So what could we do instead?
Perhaps an attestation could state that an open source project and its dependencies are sufficiently supported by manufacturers so that the project is able to set up a security team that "establish[es] and maintain[s] all necessary vulnerability management procedures in accordance with [the CRA]"?
Perhaps the attestations could even focus on the support provided by a specific manufacturer to a project to enable this? i.e. tying the attestation to a combination of a project and a manufacturer and attesting that the manufacturer support enables the level of support required to meet the manufacturer's compliance obligations?
In this example, just like in the related certification schemes, the attestations just attest facts about the project (or possibly about the support provided by a specific manufacturer to a project). They're not contracts. They can however be used as bargaining chips to fund a stronger security posture and/or meeting more essential requirements, facilitating due diligence and sustaining open source in the process.
I'm not suggesting the above example is the right solution, but I believe it illustrates an actionable way to think about this problem.
--tobie
_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org
|
