And it's not even really open, unlike ODF.
How so?
for the nitty gritty, check out groklaw.net. permalink : http://groklawstatic.ibiblio.org/staticpages/index.php%3fpag...
Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
151–158 of 158 posts
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#152Earlier quoted context omitted.
And for thousands of years humans got on with no written contracts at all. That doesn’t change the fact that as society evolves there are good reasons for agreements to evolve with it. I’m sure the first hundred years or so of written contracts there were people rolling their eyes at the idea and others “doing it wrong”. It’s possible (likely?) we’ll reach a point where strong properly implemented digital signatures…
> This stuff is hard but probably worth it ultimately. I think you're understating "hard." What about the large proportion of contracts that are still signed in paper? (All of those waivers you fill out at the doctor's office? Paper. Buy a car? Paper. Mortgage? Paper. Hire a contractor for your house? Paper.) Is your scheme going to render those invalid? Are we outlawing paper agreements? Consider also: * Many people…
Yes!
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#153Earlier quoted context omitted.
AdES is mostly an technical standard that specifies how to use existing PKCS and IETF standards to produce eIDAS conforming signature, timestamp or “seal” (ie. timestamped signature) and how that should be mapped onto CMS (CAdES), XML-Signature (XAdES) and PDF (PAdES). How legally binding the result of that process is then depends on things like QSCTs, their LoA used in that and such things. And then there are variou…
> for example in CZ, you can just generate CSR with ‘openssl req’ get that signed by right CA and produce QESs with that (and assume all the risks inherent in doing that) AFAIK that is not true. In CZ national law, there is also recognized electronic signature (RES, "uznávaný elektronický podpis"), which may be either QES (per eIDAS, "kvalifikovaný elektronický podpis"), or just AdES based on certificate from qualifi…
The point is that the CA has no way to determine that the CSR was generated by Qualified Device and will just sign it. My view of all the talk about Qualified Devices in eIDAS exists mostly to force QCAs to use normal enrollment process with CSRs instead of their random home-grown processes that result in PKCS#12 file containing private key generated who knows where and who knows how.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#154Earlier quoted context omitted.
What whole load is that? The only one I know of is the (silly) existence of the null algorithm.
For example: simply take a valid identity's public key, and use it as the secret to forge a token with alg=hs256. A service receiving this token will use its copy of the public key (by key id) to verify the signature, but because it's being told that it's an HMAC-signed token, will construct an HMAC. Of course this HMAC will verify correctly because both you (the attacker) and the server hold the same public key used…
I really don't think this is an intrinsic problem at all.
I've written JWT-parsing code and it looked for a local public key if it got an RS-algorithm and a local secret if it got an HMAC algorithm. It would be an insane implementation to treat either of them as the other.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#155Earlier quoted context omitted.
Nothing in that article mentions any kind of "fragility" in JWT's design - and the issues it documents (e.g. consumers overrwriting the signature portion) concern only extremely non-compliant (i.e. dodgy) JWT scenarios - which sounds like someone applying a bodge because they were forced to implement JWT because it was thrust onto them, usually because JWT is already so popular already - so it's nothing inherent in J…
No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format. It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.
>The only reason you don't see this said all the time in 2023 is that it was settled years ago.
Was it? If it was settled, we wouldn't keep seeing these kinds of debates.
>Cryptography engineers hate JWT.
Appeal to authority. I'm sure that they hate plenty of other things too, doesn't make their opinions or emotions automatically correct.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#156Earlier quoted context omitted.
No, none of that is true. Follow the links, too. Really, the whole article is about how to do better than JWT in an auth token format. It's always interesting to come across people who are surprised by things like JWT being considered a poor format. The only reason you don't see this said all the time in 2023 is that it was settled years ago. Cryptography engineers hate JWT.
>The only reason you don't see this said all the time in 2023 is that it was settled years ago. Was it? If it was settled, we wouldn't keep seeing these kinds of debates. >Cryptography engineers hate JWT. Appeal to authority. I'm sure that they hate plenty of other things too, doesn't make their opinions or emotions automatically correct.
It is indeed an appeal to authority. And, if you read the comment again, you'll see that you're agreeing with me: hearing that JWT is bad surprised the previous commenter precisely because we've stopped having meaningful discussions about whether JWT is good; it isn't, the case is closed, there's not much more to talk about.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#157Earlier quoted context omitted.
How so?
for the nitty gritty, check out groklaw.net. permalink : http://groklawstatic.ibiblio.org/staticpages/index.php%3fpag...
I remember reading most of those back at the time they were written.
The main one I recall for claims of not being open was that the drafts at the time had markup for marking things such as "use Word 6 line spacing" and "use WordPerfect 7 paragraph wrapping" or similar. The claim was that since those formats and behaviors were not openly documented having elements for them made OOXML not open.
That was a questionable claim for a couple reasons.
First, that markup was not there for use in newly made documents, and new word processors (including those from Microsoft) were not expected to implement it--they were expected to ignore it.
What it was there for as archiving.
For example at the time WordPerfect was pretty much the de facto standard for legal documents. Many legal publishers and large law forms stored all their documents as WordPerfect files, and had tools to manipulate those documents outside of WordPerfect. Those tools were based on reverse engineering of the WordPerfect formats.
These places had large archives of WordPerfect documents. Suppose they wanted to move to a more current, better documented archive format such as ODF or OOXML. It would be possible to write a converter that would turn a WordPerfect document into an ODF or OOXML document and change their internal document tools to understand ODF and OOXML, but since Star Office's and Microsoft Office's formatting options were not a superset of WordPerfect's that conversion would be lossy.
The straightforward way to deal with that is to find some way to add some extra data when you do that conversion to record what WordPerfect formatting options that you could not map to ODF/OOXML were in effect at a given point in the document. Make your tools understand the extra data your converter adds and then your tools can reproduce accurate copies of the originals when needed.
There were multiple parties that would be doing that. It would be silly for them to each come up with their own way to add that extra data. Some might make it custom tags. Some might make custom attributes. Some might do it with comments. Or CDATA. It would be much nicer if all the people who were extended ODF or OOXML to archive WordPerfect documents used the same way to add that extra information. That would make it easier if they ever wanted to exchange archived WordPerfect documents.
And that's what things like use "WordPerfect 7 paragraph wrapping" were: Microsoft saying "You all who have reverse engineered WordPerfect and want to mark in your document archives that some document uses some WordPerfect specific formatting, mark it this way". They did this for a bunch of older word processor and spreadsheet formats.
Second, I believe they took this out of a later draft.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#158Earlier quoted context omitted.
I’ve found the per-country overview of general legality of digital signatures on DocuSign [0] quite informative. As an example, in DK an email constitutes a valid contract for most purposes. [0] https://www.docusign.com/products/electronic-signature/legal...
Even if I spoof it? ;)
Well that’ll most likely be handled as forgery, or ‘Dokumentfalsk’ ;)