In my opinion, all of these open source/free/open document signing tools are neat on paper (and technically fulfill the goal of being able to verify a document's chain-of-custody/signature provenance) - but won't take off in any meaningful way legally because there's no entity behind them taking the responsibility for accuracy and culpability.
DocuSign/Adobe/whomever is trust anchor, it's an entity you can sue or subpoena if something goes wrong. Someone who's actually on the hook for making sure whatever's signed is accurate and truthful (outside of the reputational risk of fraud completely obliterating any trust in your platform)...
No amount of cryptographic verification substitutes for having a legal person on the other end who can be held accountable for actually verifying the document was signed accurately/process was followed.
In USA we only have a few requirements from the E-SIGN act:
Key Legal Requirements
Intent to Sign: Parties must show a clear, provable action to sign the document.
Electronic Consent: Parties must agree to use electronic records, with consumer transactions requiring specific advance disclosures.
Signature Association: The system must capture an audit trail or text linking the signature to the specific document.
Record Retention: Contracts must be accurately stored and remain accessible for future reference by all authorized parties.
Consumer Disclosure Rules
Hardware/Software Notice: Tell users what tools they need to access and save the records.
Paper Copy Rights: Inform users how to get paper copies and whether any fees apply.
Withdrawal Details: Explain how consumers can change their mind and cancel their electronic consent.
Certificates must be issued by qualified trust service providers (see section 3 for their requirements) who verify the identity of the certificate holder and ensure that the holder has sole control over the certified key. Among other things, this generally means that the key must be held in a certified HSM or smart card/USB key.
The provider infrastructure is subject to supervision of the EU member states, who accredit bodies that perform the conformity assessments.
The main purpose of all this is to ensure that the four requirements listed in article 26 are met:
"An advanced electronic signature shall meet the following requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using electronic signature creation data [private key] that the signatory can, with a high level of confidence, use under his sole control; and
(d) it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable."
Let's Seal could attempt to argue that they do ensure these requirements, but their "control of a domain" scheme is unlikely to clear that bar, and they probably also don't secure their signing infrastructure in a way that would be deemed sufficient.
that's true. i think that if it's obvious that the audit is finding everything, every detail, every file, piece of data touched.... at what level do we need to verify?
You can't be the "Let's Encrypt of" anything if it's self-hosted. The entire point of Let's Encrypt is that there is a centralized reputable entity of note signing everyone's keys. Without that, it's entirely worthless. It's no better than a self-signed SSL cert or putting your own PGP key on a document manually. There's no point in a layer of abstraction atop that.
Nice idea but with all related things the ultimate question remains whether courts will actually recognize it.
Currently courts will still consider paper-signed and scanned PDFs as legally binding, so any verification on top of that is superfluous to them.
More realistically, you take an oauth when you take the stand at the court, and if a signed document was altered by the counterparty you'd say so truthfully, if it weren't, you'd say so truthfully, and the penalty of that oauth purjury is high enough that most people wouldn't do it. Cryptography not needed.
Due to how the code signing works, timestamping servers are provided by all major CAs with full public access, e.g. timestamp.digicert.com, timestamp.comodoca.com, timestamp.sectigo.com, etc.
PS. OP, your comments are auto-killed for some reason. You may want to message mods to get this sorted.
Thanks for the heads up on the comments, ive messaged. Not sure if this will be flagged too.
Youre right, I conflated two things in my reply to sscaryterry. B-T needs an RFC 3161 token from any TSA. Its only a qualified timestamp under eIDAS that needs a QTSP. Those are separate claims I ran them together.
Although the code already has the path. The signing service uses pyhanko with an HTTPtimestamper pointed at timestamp.digicert.com, and its switched off at every call site. Reason was availability, an external TSA sits on the signing path, so if its slow or down, sealing fails, whereas the anchor is async and can never fail a seal. That reasoning holds for the default and doesnt justify never offering it.
It should be optional, and on where the caller wears the dependency, which also gets pyhanko to embed validation info and go to LTA rather than just B-T. Only thing I want to check first is the terms on those public TSAs, since a few are scoped to code signing. Opening an issue, and thx agaain.
Loved it until I saw its using Bitcoin.
With proof of work doesn’t it tie this project to a bit of an environmental nitemare? Bitcoin isn’t the best place for this, no?
I would have imagined Ethereum or some other ledger would have been better no?
Anyone with more crypto ledger knowledge be able to say what I’m trying to say more precisely.
Tried to poke a little to see if I can find any name (I could not). Challenge with this domain is the TRUST anchor. As an organization/company you have to establish yourself first (directly or through reference) otherwise its hard for anyone to trust you.
I don't like the idea of this using bitcoin. I wonder if it's possible to build this off of regular PKI - certificate transparency logs for instance encode the proof of commitment, while the signature can be an X509 certificate.
Looks interesting, but in order to actually compete with any e-signing platform you'll at the very least need to have templates with pre-filled information, an API to autofill docs with required information, and more field types. Right now for example, you can only add text, checkbox, and date/signature fields. Checkboxes are required to be checked (no making them optional), so if there are multiple checkbox options, they have to check them all to continue. Not very useful for actual e-signing flows.
It’s a neat proof of concept, but it’s hard to see the organizations that care about certified documents adopting this. Inherently conservative. Let’s Encrypt invested a lot in their early partnerships and used that to sneak up on the conservative buyers and trusters of certs.
What I think you're trying to say, but don't seem to be getting across super clearly, is that this standard hasn't yet gone through an open third party review
The idea makes sense in principle I think, and but I'll be chewing on it a bit, haha. Seems like a solid standard, but you know how standards go.... (Relevant XKCD: https://xkcd.com/927/)
I like that you kept a lot of the same commands/naming/syntax from LetsEncrypt. As someone familiar with LetsEncrypt, makes me feel like I'd slide right in here easily.
I'd like to learn more about the 'Bitcoin anchored root'...is that part of RFC 6962 or something else entirely? Do you mean a 'Bitcoin-like blockchain' or are you using the actual BTC chain? Could you point me in the right direction?
It's astonishing how easy it is for an LLM to convince its user they have an idea worth a genuinely sound standard, let alone an open standard.
Each open standard where it's clear the only consultation was between the prompt engineer and Claude is as tedious as the weekly cryptocurrency whitepaper of the mid-2010's.
The only novel factor in the proliferation of lazily prompted open standards is we have a perfect demonstration of the futility of LLLM sycophancy when combined with a mind looking for an easy win.
A few months ago, I released the Open Claiming Protocol, in order for an interoperable, open standard for people cryptographically signing things. I wonder, how does this overlap with that, and could it be useful to support it? I agree it's much more general purpose though...
I know that there are some sites, like proofofexistence.com that acts like a notary service anchored to Bitcoin. Is that similar?
To me, it seems that there are some secret things you might want to hash and sign, and timestamp, like agreements that you can prove that both parties signed them, etc.
In my opinion, all of these open source/free/open document signing tools are neat on paper (and technically fulfill the goal of being able to verify a document's chain-of-custody/signature provenance) - but won't take off in any meaningful way legally because there's no entity behind them taking the responsibility for accuracy and culpability.
DocuSign/Adobe/whomever is trust anchor, it's an entity you can sue or subpoena if something goes wrong. Someone who's actually on the hook for making sure whatever's signed is accurate and truthful (outside of the reputational risk of fraud completely obliterating any trust in your platform)...
No amount of cryptographic verification substitutes for having a legal person on the other end who can be held accountable for actually verifying the document was signed accurately/process was followed.
Indeed. It doesn’t meet the requirements of EU qualified signatures or seals, for example.
What are the actual requirements?
In USA we only have a few requirements from the E-SIGN act:
Key Legal Requirements
Intent to Sign: Parties must show a clear, provable action to sign the document. Electronic Consent: Parties must agree to use electronic records, with consumer transactions requiring specific advance disclosures.
Signature Association: The system must capture an audit trail or text linking the signature to the specific document.
Record Retention: Contracts must be accurately stored and remain accessible for future reference by all authorized parties.
Consumer Disclosure Rules
Hardware/Software Notice: Tell users what tools they need to access and save the records.
Paper Copy Rights: Inform users how to get paper copies and whether any fees apply.
Withdrawal Details: Explain how consumers can change their mind and cancel their electronic consent.
See eIDAS annexes I to III: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
Certificates must be issued by qualified trust service providers (see section 3 for their requirements) who verify the identity of the certificate holder and ensure that the holder has sole control over the certified key. Among other things, this generally means that the key must be held in a certified HSM or smart card/USB key.
The provider infrastructure is subject to supervision of the EU member states, who accredit bodies that perform the conformity assessments.
The main purpose of all this is to ensure that the four requirements listed in article 26 are met:
"An advanced electronic signature shall meet the following requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using electronic signature creation data [private key] that the signatory can, with a high level of confidence, use under his sole control; and
(d) it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable."
Let's Seal could attempt to argue that they do ensure these requirements, but their "control of a domain" scheme is unlikely to clear that bar, and they probably also don't secure their signing infrastructure in a way that would be deemed sufficient.
that's true. i think that if it's obvious that the audit is finding everything, every detail, every file, piece of data touched.... at what level do we need to verify?
You can't be the "Let's Encrypt of" anything if it's self-hosted. The entire point of Let's Encrypt is that there is a centralized reputable entity of note signing everyone's keys. Without that, it's entirely worthless. It's no better than a self-signed SSL cert or putting your own PGP key on a document manually. There's no point in a layer of abstraction atop that.
To be fair, they do host it. And they do have their own trust anchor.
If you recognize it or not, is another topic.
Nice idea but with all related things the ultimate question remains whether courts will actually recognize it.
Currently courts will still consider paper-signed and scanned PDFs as legally binding, so any verification on top of that is superfluous to them.
More realistically, you take an oauth when you take the stand at the court, and if a signed document was altered by the counterparty you'd say so truthfully, if it weren't, you'd say so truthfully, and the penalty of that oauth purjury is high enough that most people wouldn't do it. Cryptography not needed.
This depends completely on the jurisdiction. This is simply not universally true.
*oath. For a while it got me wondering how OAuth figures in all this.
Why not use RFC 3161?
Due to how the code signing works, timestamping servers are provided by all major CAs with full public access, e.g. timestamp.digicert.com, timestamp.comodoca.com, timestamp.sectigo.com, etc.
PS. OP, your comments are auto-killed for some reason. You may want to message mods to get this sorted.
Thanks for the heads up on the comments, ive messaged. Not sure if this will be flagged too.
Youre right, I conflated two things in my reply to sscaryterry. B-T needs an RFC 3161 token from any TSA. Its only a qualified timestamp under eIDAS that needs a QTSP. Those are separate claims I ran them together.
Although the code already has the path. The signing service uses pyhanko with an HTTPtimestamper pointed at timestamp.digicert.com, and its switched off at every call site. Reason was availability, an external TSA sits on the signing path, so if its slow or down, sealing fails, whereas the anchor is async and can never fail a seal. That reasoning holds for the default and doesnt justify never offering it.
It should be optional, and on where the caller wears the dependency, which also gets pyhanko to embed validation info and go to LTA rather than just B-T. Only thing I want to check first is the terms on those public TSAs, since a few are scoped to code signing. Opening an issue, and thx agaain.
Any benefits over DocuSeal?
https://github.com/docusealco/docuseal
Loved it until I saw its using Bitcoin. With proof of work doesn’t it tie this project to a bit of an environmental nitemare? Bitcoin isn’t the best place for this, no?
I would have imagined Ethereum or some other ledger would have been better no?
Anyone with more crypto ledger knowledge be able to say what I’m trying to say more precisely.
Tried to poke a little to see if I can find any name (I could not). Challenge with this domain is the TRUST anchor. As an organization/company you have to establish yourself first (directly or through reference) otherwise its hard for anyone to trust you.
I don't like the idea of this using bitcoin. I wonder if it's possible to build this off of regular PKI - certificate transparency logs for instance encode the proof of commitment, while the signature can be an X509 certificate.
The standards exist. The problem is, the certificates are not cheap, because there is real KYC needed.
https://en.wikipedia.org/wiki/PAdES
Looks interesting, but in order to actually compete with any e-signing platform you'll at the very least need to have templates with pre-filled information, an API to autofill docs with required information, and more field types. Right now for example, you can only add text, checkbox, and date/signature fields. Checkboxes are required to be checked (no making them optional), so if there are multiple checkbox options, they have to check them all to continue. Not very useful for actual e-signing flows.
It’s a neat proof of concept, but it’s hard to see the organizations that care about certified documents adopting this. Inherently conservative. Let’s Encrypt invested a lot in their early partnerships and used that to sneak up on the conservative buyers and trusters of certs.
I'd be very careful with this. Looks to me like an invented standard: https://letsseal.org/site/standard
Aren't all standards "invented"? Do you want to say that there is no a RFC page for the protocol?
Edit: spelling
Sure, lets say this lacks an RFC/ISO number, or any semblance of what is usually called a standard.
What I think you're trying to say, but don't seem to be getting across super clearly, is that this standard hasn't yet gone through an open third party review
Poked around a bit..excited to see where this goes.
Just a quick note, Under "Get help from the community > Disucssions", there's a 404 to https://github.com/letsseal/letsseal/discussions .
The idea makes sense in principle I think, and but I'll be chewing on it a bit, haha. Seems like a solid standard, but you know how standards go.... (Relevant XKCD: https://xkcd.com/927/)
I like that you kept a lot of the same commands/naming/syntax from LetsEncrypt. As someone familiar with LetsEncrypt, makes me feel like I'd slide right in here easily.
I'd like to learn more about the 'Bitcoin anchored root'...is that part of RFC 6962 or something else entirely? Do you mean a 'Bitcoin-like blockchain' or are you using the actual BTC chain? Could you point me in the right direction?
It's the actual BTC chain, it's based on https://opentimestamps.org
I love the concept, it would be great to see broader uptake of an open standard for this sort of space.
Thx. The spec matters more than the site here, its SPEC.md in the repo. Still v1.1 and cheap to change, so any/all notes welcome.
Is this PAdES B-B only? As far as I know, PAdES B-T requires a QTSP timestamp.
It's astonishing how easy it is for an LLM to convince its user they have an idea worth a genuinely sound standard, let alone an open standard.
Each open standard where it's clear the only consultation was between the prompt engineer and Claude is as tedious as the weekly cryptocurrency whitepaper of the mid-2010's.
The only novel factor in the proliferation of lazily prompted open standards is we have a perfect demonstration of the futility of LLLM sycophancy when combined with a mind looking for an easy win.
How does it compare to DocuSeal?
A few months ago, I released the Open Claiming Protocol, in order for an interoperable, open standard for people cryptographically signing things. I wonder, how does this overlap with that, and could it be useful to support it? I agree it's much more general purpose though...
http://openclaiming.org/
I know that there are some sites, like proofofexistence.com that acts like a notary service anchored to Bitcoin. Is that similar?
To me, it seems that there are some secret things you might want to hash and sign, and timestamp, like agreements that you can prove that both parties signed them, etc.