(continuing top posting to keep thread consistent) Note that the point of using an X.509 signature at file creation time and/or client approval time was to reuse the internal file structure that is already designed to hold that particular signature format (specifically, the internal file structure that would eventually hold the final signature, which was already specified to be in that format). Thus the idea was to simplify and reuse code, given the existence of code, tools and data formats to sign those particular files with X.509 signatures. This was also (presumably) the reason Microsoft did it this way. But yes, of cause if the file generation is already secure, then the secure file generation machine should apply an initial signature and the client just add some kind of counter-signature authorizing this particular one of the securely generated files. On 24/06/2015 15:24, Michael Wojcik wrote: > > In Marco's original description, the file is created by a trusted > system and then transmitted to the client. Then, later, the client > transmits it to the server, which verifies the contents. If the file > is signed by the creating system, it doesn't matter if the client is > compromised. A compromised client can refuse to send the file, or it > can send a forged or corrupted file, but the server can dectect all of > those cases. > > It's not clear from Marco's description whether the system that > creates the file can perform the signing process, but I don't see any > reason (in the description) why not. It would help if this point were > clarified. > > The Windows driver-signing process and similar look wildly > overengineered for Marco's purposes, if my understanding of his > requirements is correct. They have a very different threat model - and > that's why this isn't "a common requirement". Windows drivers are > created by thousands of organizations and consumed by thousands of end > users. Marco has files created on a trusted system (or handful of > trusted systems) he controls, and verified by trusted systems he controls. > > His followup message below says "data has to be signed with an X.509 > certificates public key that already exists". I'm guessing this > actually means "data has to be signed with the private key > corresponding to a public key that happens to be in an X.509 > certificate that already exists". That doesn't mean X.509 PKI must be > used; X.509 isn't some sort of virus that infects everything it > touches (appearances to the contrary). There's an asymmetric key pair > of some sort - RSA probably - and we need to use it for signing. Fine. > > Here's what I'd do: the originating trusted system creates the data > and runs "openssl rsautl -sign" with appropriate parameters to create > a signature. (Just script the openssl command-line utility; this is a > trusted system, so why reimplement the code?) Add the signature to the > proprietary file format. Send the whole thing to the client. > > Client subsequently sends the signed data and signature to the server, > as part of a file in the proprietary format, along with whatever > unsigned data is included. > > Server extracts the signed data and signature, and uses "openssl > rsautl -verify" to verify it. > > Michael Wojcik > Technology Specialist, Micro Focus > > (original text snipped) Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150714/0254891a/attachment.html>
