 yes dog thank you my name is Olivier so Ronnie are you here I know that you're gonna yes I'm you yeah dog I would like to can you hear me right so if he is speaking yes we do hear you okay okay would you mind sharing your screen when you are not creating a signature but a very fine existing one done what we were doing is basically checking if the hash is matching in the signature and actual document so we call this if the digest is matching then we will do verification of the certificates of this X 509 certificates and we also check if the whole document is signed so these are the cases how the whole signature verification can fail and in case any of these are missing them you get some kind of warning or error and in case all of these are matching them even the LibreOffice window title is modified that saying that this is a signed document and all of this is based on X 509 certificates so for the scope of this talk I'm not talking about the GPG based signing and encryption rather this X 509 certificates this is the same stack that's used for HTTPS and in general for encrypted connections at the TCP level as well usually so the first thing that appeared in LibreOffice that was new in the area of digital signing about four years ago was OXMAS signing so signing of DOCX, XLSAX, PPTX files which is somewhat similar to ODF signing because W3C published the specification on how the core of such a digital signing should be performed on XML files and ODF is building on top of that and OXMAS does the same in a bit different way but at its core it's really the same idea. What's specific about OXMAS signing is that it's not signing the metadata of the document like last modified date, last print date, outdoor name and so on which means that in case you open these files in LibreOffice then the best you can reach is this is almost perfect but the document is only partial this time you will never get a perfect signature due to this. It's important that we try to handle existing signatures from Microsoft Office and also what we create is meant to be verified successfully in Microsoft Office. It's somewhat interesting that it has all this W3C SPAC around the XLSAX signing is working with various transforms so you have your input data, you process that through a list of transforms and you do your hashing and encryption and as part of that OXMAS has a custom transform algorithm of this relationship transfer algorithm which is used for the piece where the various XML files and does it point in or referring to each other. This is really more like a map so you can look up various keys in that and the values are the various streams in the zip file which means that ordering of these is not interesting and in the files typically they are not ordered so they need an extra stuff for sorting these and preparing them in a way that even if you change the order of these relationships the signature is not invalidated and that was this supported algorithms were hardcoded in the XML SAC library so first I had to improve the XML SAC library to support this transform and then do the work on the LibreOffice sign. The other somewhat interesting detail about OXMAS signing is that the markup is designed in a way to leak all sorts of software and hardware details so it's a bit awful like you have to state what's your Windows version, what's your Microsoft Office version, what are the details of your monitor and whatnot and in case you don't do that then work is refusing to verify your signature. So we have some hardcoded steps on the LibreOffice side stating something because if the information is there then it's not a problem it's actually not real information but something has to be filled in there. Now the next set of features that were added to LibreOffice in the area of digital signing is PDF files. So the first thing was that we already had PDF export so it makes sense to do PDF signing as part of the PDF export so you have some editable document you do an export to a PDF file and as part of that export to PDF an optional single PDF signature can be added. This was started as a GSOC project and quite some work was done there but sadly it did not reach a state where actually the ending signature would be validated in Adobe Acrobat and Torlic West was finishing that with the last backfixes. So now we can do a standard PKCS7 binary signature and that to the PDF file and typically various PDF readers can verify the signature. Now the other thing we did is that once you have such a PDF file then we want to verify that and that's a much much more problematic. Much more code had to be added there and you had to work yourself through various layers and noticing all sorts of complexity that you did not really expand. So it was a bit of crying realizing how much work this requires but then it was working. So what was first has to be decided is what we were used to parse the input PDF file and we already had about three PDF parsers and sadly it was necessary to add a force one just because none of the existing tree was providing the requirements that was necessary here. So we already have a popular based PDF parser which is used in case you open a PDF file in draw and you want to map that to something editable and udg-fine. We also have a boost base minimal parser which is I believe used for hybrid PDFs so in case you have such a PDF then the original editable content will be open in right or calc impressed and for that we are not using popular and for inserting PDF images and various other smaller PDF related things we also have PDF view which would be the best candidate for parsing doing parsing for signature verification purposes but at least back then it had no API to deal with signatures. Nowadays it's close to a feature site that we would need so that could be a future direction to switch to that but at least back then that was far from enough what they were providing. So the basic verification of such a PDF file is not that complicated assuming that there is a single signature in the PDF then there is that binary signature in the file in a Hextump. You need to find that and read all the data before and after that signature and you have to hash it and then compare if the hash in the signed signature binary is the same as the hash you get and then you do your usual certificate validation. So that's not complicated. The problem is that you can always apply new content to the end of a PDF file as in the form of an incremental update and that introduces all sorts of complexity. Like the first one is you perhaps want multiple signatures but strictly speaking only the longest signature of the five will be valid because you added something new to the end of the file in a second signature. Still by definition your first signature is no longer covering the full document so strictly speaking the first signature is no longer valid. Of course in real world people want PDF signatures where multiple signatures are on the file and they are still valid. So you enter in some kind of gray zone where you say that what technically this is not valid but let's still accept that and then you have all sorts of trouble. Should we still accept this or this is now enough nonsense that this is invalid. All sorts of corner cases. So it's a bit sad that the PDF format is designed in this way that it does not allow perfect multiple signatures. What it is what it is we have to live with that. What you can also do is a signing of existing PDF files. So in the simplest case you have an un-signed PDF file and you want to add some new content at the end so that you turn that to a signed PDF file. This is working even with combination of Adobe Acrobat. So you can do all sorts of combinations of first doing your initial signature there and then the subsequent signature in Libreface or other way around. And given that at least when this was first update we were still producing PDF 1.4 files not using any of the newer markup but it's possible to create some newer PDF in Adobe Acrobat and we want to still sign those things. All sorts of new PDF markup support was was added to this PDF file which is focused on signature handling. Instead of a more or less plain text cross-reference table at the end of the file you can have compressed binary cross-reference streams. Also for loads of small PDF objects in the file you can turn that to a compressed object stream. You can compress the stream in different ways with all sorts of different compression algorithms and parameters for that. We had to support all this so that in case you saw a random file created in Adobe Acrobat, throw that file on Libreface and want to sign that file then we can actually support it. I believe we now have decent support for this. The frequently used combinations are working nicely. Now on top of existing XML signing or XML signing and PDF signing you can have support for the Xadas and Padas standards which are coming from the EU. They are a set of extensions to this XML signing and PDF signing. The promise they are providing is that if all the conditions are met then this can result in a legally binding signature which makes it a very interesting feature. Perhaps now this won't be a toy signing anymore but rather it will be the equivalent of physically signing a paper. But that again introduced all sorts of new requirements. The support for stronger hashing algorithms was needed so the SHO256 support was added next to RSA also the new or ECDSA encryption algorithm was necessary to be supported. One reasonably easy thing to do but it's very important is that the signing certificate is not part of the signed data which means that normally you have a signing certificate that has your name on that and some expired date and whatnot. One other item is the core of the certificate, some private key in the signing certificate and then you have some matching public key for that and you are embedding that public key to the signed document. The problem is that then you can have this attack that you create a second signing certificate which will contain the same private key but it will have a completely different name. That means that basically the signature was previously just proving that the document was signed to the given private key but it was not proving that it was signed with the given signing certificate and you as a human in the real world actually want to prove with the signature you want to prove that a certain person with a given name was signing that document so that's why this is important. At least for the PDF part I was going to mention later we are passing the SSVLiDator, the Digital Assign Services VLiDator. This is some Java application produced by the EU and our PADAS output is passing that at least the basic level is passing so that's very nice. Note the last major feature that was added in the area of digital signing is a new VCR adding support for visible signatures. Now what that means is that previously in case you added some signature to the document that was more like just a metadata. We were adding some signatures to the document at the first page, zero size top left corner and we wanted to and that was not really visible when you were viewing the document. Just perhaps your PDF reader was pointing out that this document is signed. But if you do the same in the Adobe Acrobat then something visible as a widget was added to the document and then we support the same. And actually the currently provided feature start is in some areas even superior to what you got from a paid document or the free version Adobe Acrobat. So we do a vector based graphic as a signature widget. It's not a bitmap but you zoom in and it looks poor. We properly as I say the signature widget with the actual visible signature markups of this hubs accessibility. And also it's a two step process. So first you can insert your your signature rectangle. You can find you in the size and position and then later you will do the actual assembly. So a combination of all these three is something that LibreOffice provides but not these others. So that's a nice experience I guess. Now the question is like how this is what you see as a user but how is this working in some deeper level. So one thing that was added is a signature descriptions. This is something that works among PDF already has markup before. But for already of this has had to be added. And this means that it makes no it makes sense to sign the same document multiple times. Because you can have some comment or reason or description field. And there you can state like what what do you state by creating the signature. In case you are you have multiple reasons to sign a document. For the OXMOS signature import. As mentioned one one thing that had to be done is this relationship transform algorithm implementing that and also submitting to upstream and XML stack library getting a review there. Making sure that even the XML stack library maintenance is understanding what's going on there and agreeing that this is the correct implementation for that. In the XML security module in the core repository. We have a small XML parser for the actual XML signature. And also what was what needed extending is that previously when we were checking if the document signature can be created or or verified we were just checking if this is ODA because we know nobody else says no other format is supported in digital signatures. But now we had a second set of formats the OXMOS formats for for signatures. So you know there is a new filter flag saying import or export flag saying that this format supports digital signing. And some refactoring in XML security was needed so that most of the signature logic is now living not in the dialogue but in a separate class and then you can write nice CPP unit tasks for next. I would try to be progressing a bit faster so that we still have time for questions as well. So for the signature export. Basically we had to do the opposite of the import flag. Somebody had a question or wanted to say something or not. OK, let's take as I know. So the import side of what had to be supported is creating the initial signature or appending a second or sort signature to the document. These are different cases and we have separate files for the for the individual signatures, which is on one hand makes life easier because you can just run three of the files as is unlike in ODF. On the other hand, then you have to have some list of references to these files and you have to maintain that list and make sure that that's always kept up today. For verifying existing PDF files what was an additional user interface is that when you open some document for that's already signed or you open it for signing, then we have some additional UI discouraging you from editing the PDF file because then you will lose your existing signatures. For the part of support here is a small simple screenshot of passing that that validator. What what was new is that now we default to this stronger shout 256 hashing algorithm for PDF signatures and we embed this signing certificate and on the import side, we don't do the full PADES verification, but at least we can point out that if this signature is containing any sort of signature or PADES signature. Now, separate bit was being support for this ECDSA encryption algorithm, which was particularly painful because on Windows, we were using some on the other Windows API, which was not supporting this. And I had to port over all the hashing and algorithm code on the LibreOffice side from this other API to this Microsoft CNG, which is supporting ECDSA. But at the end, then resulted in some nice feature where you can encase your countries for providing these electronic IDs for you, like Angoridus, for example, that you can use, do some real hardware based, hardware key based signing inside LibreOffice and it's working nicely, integrates with the TriGoron soon. And for the last feature for the PDF signing, I tried hard to reuse existing code and not trim on the wheel. So the user interface is very similar to signature lines, which is already available in writer and CULC. Also, the generated PDF markup is using this feature that you can select the shape and export that shape to PDF, just that single shape. We are generating for the PDF, like for the visible PDF signature, we feature your the signing date, for example, that's nicely locale aware as you would expect from LibreOffice. And also, this is working with multiple signature, multiple pages and so on. To give credit, most of this work was sponsored by the Dutch Ministry of Defense and small company now in the Netherlands. So that's why it was possible to make this work available for now for everyone, given that, like at Colbert on VR, making all of our work open source. So if we do some things, somebody has to pay for them. So I guess this is it. The summary is that signature descriptions or this status and status standards are no supported, stronger hashing algorithms, more modern encryption algorithms are supported. We are hopefully basically on par with Microsoft Office and Adobe Acrobat does with their native file formats. And this later saying this year was the visible PDF signatures. So thanks for listening. And I wonder if there are questions like we have still about several minutes for questions in case there is an answer, at least now I switch to the chat window and see I'm not offline for like 20 minutes. So that's that's great. So till somebody came up with some question. One detail I can share with this how to eliminate that four different PDF parsers that we have, which is like, very annoying. The hope is that at least this is just for signature purposes, that can be hopefully eliminated. And we could use PDF install. It's just there is this lockstop all the time that Ebrofis wants this and that detail of the PDF file. And then we want to use some public PDF in API to get that information from the PDF file. So I go to the PDF in project discuss the RF it makes sense to add that information to the public API. Then finally, you get a go from PDF in that saying that it makes sense to implement that. So you implement that, and then you wait some time till we update the bundle PDF in version in the process, so that we have that API available. And then you hope that in the meantime, there is no required more new requirements and new detail needed on the profile side on that some stage. Hopefully, we will bundle some new enough PDF in which to provide all the details that we need. And then we can switch to the actual switches not that complicated, but small complicated as that. Initially, PDF you was just focusing on just rendering a PDF file. And for rendering, you need less information compared to what you need for digital signing. So first, we need to kind of improve PDF in so that provides everything what we need. So that's a longer term saying what I still believe that we can we can get there at some stage. Any questions at all? Yeah, I thought I make law score here. I thought someone fellow just raised his hand to say something. No, but I have no idea who who it was how this works. But yes, it was in case it was you who raised your hand, then please ask your question. Thank you. No, may have been hit on the R key, raise hands by accident. Maybe. Yeah, that's quite possible. If no one asks. Okay. Okay, so in case there are no questions, then thank you for your attention. And enjoy the rest of the conference. Thanks. Thank you very much.