<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New","serif";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.code, li.code, div.code
{mso-style-name:code;
mso-style-priority:99;
mso-style-link:"code Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:Consolas;
color:black;}
span.codeChar
{mso-style-name:"code Char";
mso-style-link:code;
font-family:Consolas;
color:black;}
span.moz-smiley-s1
{mso-style-name:moz-smiley-s1;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:319427267;
mso-list-template-ids:-300368878;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New","serif";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1929195536;
mso-list-template-ids:-12135420;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Server extracts the signed data and signature, and uses "openssl rsautl -verify" to verify it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Courier New","serif"">Michael Wojcik</span><span style="font-size:9.0pt;color:#1F497D">
<br>
</span><span style="font-size:9.0pt;font-family:"Courier New","serif"">Technology Specialist</span><span style="font-size:9.0pt;font-family:"Courier New","serif"">, Micro Focus</span><span style="font-size:9.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> openssl-users [mailto:openssl-users-bounces@openssl.org]
<b>On Behalf Of </b>Jakob Bohm<br>
<b>Sent:</b> Wednesday, June 24, 2015 01:53<br>
<b>To:</b> openssl-users@openssl.org<br>
<b>Subject:</b> Re: [openssl-users] beginner needs advice on data signature/verification<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p>(Continuing top posting to keep thread consistent).<o:p></o:p></p>
<p>First of all, if the client itself is compromised, the file content can be compromised just before you do whatever you do to assure the server that this was what the user of the client wanted. No way to fix that other than to keep the client free of compromise.<o:p></o:p></p>
<p>Now the common solution used by driver and program signing programs such as Symbian signed (discontinued), Windows driver package signing for compatibility, Windows driver binary signing for Windows 10, and older versions of Windows Mobile 5.x/6.x signing
is this:<o:p></o:p></p>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Client has a unique X509 certificate with a private key known only to that client. Doesn't matter who issued the certificate, but the server needs to have its own known genuine copy of that certificate. That certificate should be such that no one except that
client and that server trusts things for being signed by it.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Client signs the file/message with its private certificate exactly as if that would be the final signature (even though almost no one will trust it).<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Client sends signed file/message to server.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Server verifies the signed file/message using its private list of trusted client certificates.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Server maps the verified signature to the identity to be used for the final signature.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Server talks to its closely related CA to get a brand new single-use-only certificate for the identity (with a serial number added as an extra subject name element).<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Server removes the client signature and signs the file/message with the brand new certificate for the final identity.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Server throws away the private key, so that no more files can be signed with that certificate, ever.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
If the server ever signs anything by mistake, it (or an admin if the server was permanently compromised) asks its closely related CA to revoke the affected single-use certificate.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
If the client certificate needs to be revoked due to the certificate or its user being compromised on some current or past time/date, the related CA revokes all the single-use certificates for that identity since that date/time. Other/replacement client certificates
for the same (visible) identity remain valid because single-use certificates for those requests were never revoked.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
Note that in this setup, there is no need for a time stamping service, simply give the single-use certificate the long (listed) lifetime, and rely on the uncompromised server diligently deleting the private key within a few seconds after creating it.<o:p></o:p></li></ol>
<p>Of cause you don't need to make this entire "temporary certificate" dance (steps 6, and 8 to 11), for instance if the server will be using certificates issued by one of the pay-per-certificate public CAs, the server will instead need to keep around a certificate/private
key pair for each public identity, and may need to use a public time stamping service just as if it was a normal direct end-signer.<o:p></o:p></p>
<p>As for the format, putting S/MIME aka CMS aka PKCS#7 format signatures inside a file format, look at how Microsoft did this with its AuthentiCode concept and how Sun/Oracle did with its jar format. Its almost the same procedure with 5 minor differences:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
AuthentiCode sets the PKCS#7 content-type to an AuthentiCode specific OID, jar file use the generic "data" OID. At least some members of OpenSSL team suggest that using any OID other than "data" is not allowed by more recent versions of the CMS standard.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
AuthentiCode signs a custom DER encoded ASN.1 structure with the relevant attributes and secure hashes of the parts of the signed document that don't depend on the value/size of the signature blob itself. Jar signs a formatted text file with that same data.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
(classic) AuthentiCode uses the original countersignature format and attribute for timestamping, requiring a timestamping service that creates "bare" signatures of the small blob sent for timestamping, jar files may or may not use a slightly different format
allowing use of the newer RFC-based timestamping protocol.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
Some implementations of jar signature validation (most notably the one used by Mozilla/Firefox/Thunderbird) requires the certificates to have the attributes of the historic "object signing" protocol, AuthentiCode and most other jar implementations simply require
the relevant extended usage attribute in the end certificate. Commercial code/object signing certificates tend to include the extra attributes to work for both.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2">
The two formats sometimes forget to check different obscure parts of the file being signed for some file formats. I won't elaborate on which ones.<o:p></o:p></li></ul>
<p>From this list of differences and similarities, it should be somewhat easy to make sane choices for how to design your own use of X.509 certificates. Note that if the items being signed are documents rather than program-like objects, you should probably
check for the e-mail signing or document-signing extended usage attribute, not the object-signing one.<o:p></o:p></p>
<p class="MsoNormal"><br>
On 23/06/2015 19:55, Marco Warga wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Many thanks for the answer.<br>
<br>
I should have been more specific on the requirements right away. The "file" was really just an example to keep it simple. Reading my own writing, I would probably have suggested what you did
<span class="moz-smiley-s1">:-) </span><br>
<br>
So here are the facts:<br>
- client/server are not connected to the internet<br>
- the network protocol is existing and proprietary<br>
- the file structure is existing and proprietary, but can be extended to allow for additional signature information to be embedded that will be sent to the server<br>
- the data actually transferred (and to be signed) is part of that file<br>
- the data has to be signed with an X.509 certificates public key that already exists<br>
<br>
S/MIME does pretty much do what I want to do. However the network protocol or the data to be signed cannot be changed for compatibility reasons. Under these circumstances, I don't really see how I could achieve my goal easier than by openssl directly.<br>
<br>
Considering the "very common requirement": I was thinking of i.e. windows driver signatures, android/ios app signatures and similar mechanisms to ensure that files are from a trusted source.<br>
<br>
Am 22.06.2015 um 14:44 schrieb Michael Wojcik:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Response inline below, prefixed with "MW". (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> openssl-users [<a href="mailto:openssl-users-bounces@openssl.org">mailto:openssl-users-bounces@openssl.org</a>]
<b>On Behalf Of </b>Marco Warga<br>
<b>Sent:</b> Saturday, June 20, 2015 04:48<br>
<b>To:</b> <a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<b>Subject:</b> [openssl-users] beginner needs advice on data signature/verification</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
I hope some of you could give me advice on my project using openssl.<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it
on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here
is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit.</span><o:p></o:p></p>
<p class="MsoNormal"><br>
Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I
need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MW: No, but that's probably because what you've described isn't "a very common requirement". It's too vague. We don't know what problem you're actually trying
to solve. It may be that you just need to send a file with a verifier, which - as I noted above -
<i>is</i> commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC.</span><o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do:<br>
<br>
1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file.<br>
2.) Have the client send that data file to the server (cert/sig first)<br>
3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert()<br>
4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><br>
Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In
other words, it's safe as long as the private keys are neither leaked nor forced.</span><o:p></o:p></p>
<p class="MsoNormal"><br>
Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler
yet. There are any number of examples online for signing a file and verifying its signature.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</blockquote>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>Enjoy<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Jakob<o:p></o:p></pre>
<pre>-- <o:p></o:p></pre>
<pre>Jakob Bohm, CIO, Partner, WiseMo A/S. <a href="http://www.wisemo.com">http://www.wisemo.com</a><o:p></o:p></pre>
<pre>Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10<o:p></o:p></pre>
<pre>This public discussion message is non-binding and may contain errors.<o:p></o:p></pre>
<pre>WiseMo - Remote Service Management for PCs, Phones and Embedded <o:p></o:p></pre>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="background:white"><o:p> </o:p></span></p>
<p align="center" style="text-align:center"><span style="background:white">Click <a href="https://www.mailcontrol.com/sr/+EU4+0k7Vr3GX2PQPOmvUqEZpHzWxmiIsPf!4dFwdh+tWt2FLtByw1qK67VWoRuzREr2Onn45QSVGm43FW9a3A==">
here</a> to report this email as spam.<o:p></o:p></span></p>
</div>
</div>
</body>
</html>