Re: Web signing?
Thanks Nelson for explaining this. I also understand your worries regarding what to sign and I would be very dishonest if I said I have solved it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the viewer works as expected. Now, why don't I feel that this is a huge limitation? First a legal issue. Based on *actual* court cases you can indeed be convicted based on IP addresses if you are found downloading forbidden data. I.e. digital signatures are simply a stronger evidence. Then a practical issue. If a crooked site asks you to sign a form that in some way is camouflaged (using overlaid HTML) into something else, the question is really what the crooked site can do with that unless the crooked site actually is a genuine representative of your government, bank, or employer. That is, in spite of all the legal trauma associated with signatures, authentication is actually MUCH more critical because there is nothing to repudiate in the case somebody cracked your medical file etc. You may be interested (still awake?) knowing that payment operations in brick-and-mortar shops is ultimately the most important application for the suggested scheme. Since this list doesn't really work with payments, I won't bore you to death with how this is supposed to work, but it does! Anders If you really want to test Web Signing you can try this proxy setup http://upi-using-service.webpki.org/IncomeDeclaration use PIN 1234 :-) - Original Message - From: Nelson Bolyard [EMAIL PROTECTED] To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Thursday, November 20, 2008 00:07 Subject: Web signing? Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS DB migration problem
Hi, Hans Petter Jansson schrieb: This database only fails to migrate if the target database was not already created by another, successful merge, though. I think you're saying that the failures only occur if the target (cert9) DB doesn't already exist when your program is run, but does succeed if the target is already a legit cert9 DB. Is that what you're saying? That would not surprise me. I think that the function you're using, NSS_InitWithMerge, does assume that the target DB already exists. Almost. I'm saying that if the database fails to migrate the first time, and leaves an empty database, then subsequent merges to that database also fail. However, if the first merge is successful (creating the database and populating it), then subsequent merges always work. I have a small sample size, though, since I don't have (nor want, really) direct access to other users' databases. It looks like Wolfgang found the problem, or at least a problem, in the Firefox' password manager thread, so I'm going to test using a normal NSS_Init() to create the database if it doesn't already exist, and see if that works. Thanks, Wolfgang :) I _think_ the problem when creating a new database (if one doesn't already exist) using NSS_Init() could be that the internal token (SDR) is created and people will never be able to read their passwords again even after a merge? I think what should be done is to mimic exactly what certutil -L -X -d sql:. is doing for the initial creation of the database? Wolfgang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Anders Rundgren wrote: I also understand your worries regarding what to sign and I would be very dishonest if I said I have solved it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the viewer works as expected. Now, why don't I feel that this is a huge limitation? First a legal issue. Based on *actual* court cases you can indeed be convicted based on IP addresses if you are found downloading forbidden data. I.e. digital signatures are simply a stronger evidence. I suspect you have spent too long in the fluffy who cares world where when presented with an agreement to sign, you just blindly click on the accept button trusting that the agreement that was never read contained nothing harmful to you in any way. Having designed a system that includes web signing using crypto.signtext() for an insurance company to handle claim approvals, I can tell you that the primary question of the business people who used the system was just what are we signing exactly?. In the case of crypto.signtext(), the end user is presented with a piece of human readable text, and the end user can choose to sign or not sign that human readable text, as appropriate. That user readable text is the beginning and end of what they are asked to sign. Signing a form is completely meaningless, because the user is not given a full, complete and unambiguous entity for them to sign. Then a practical issue. If a crooked site asks you to sign a form that in some way is camouflaged (using overlaid HTML) into something else, the question is really what the crooked site can do with that unless the crooked site actually is a genuine representative of your government, bank, or employer. Seriously, if you cannot fathom the security risk posed by someone asking you to sign an agreement when you cannot see the full agreement you are signing, then you seriously should not be trying to design any secure systems at all. Seriously. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. Right, Anders pointed me to this in private email: http://upi-using-service.webpki.org http://webpki.org/ There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? Right. In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. And in other countries, how do we know that it is a sign of intent? I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. Well, my first thought was: this can't work, for all the normal reasons why digital signatures don't work. My second thought was, gee, I need it in a project I'm working on. Oops! Hmmm... I wonder what my third thought will be... Seriously though, I can see lots of applications for it, but the infrastructure required makes this less of a tech concept and more of a legal / document management management concept is missing in most contexts. This is a business problem not a tech problem. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Anders Rundgren wrote: I also understand your worries regarding what to sign and I would be very dishonest if I said I have solved it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the viewer works as expected. But it's the main issue! If you don't address this it's simply worth nothing. And you're bashing S/MIME use. Ah well... You may be interested (still awake?) knowing that payment operations in brick-and-mortar shops is ultimately the most important application for the suggested scheme. Since this list doesn't really work with payments, I won't bore you to death with how this is supposed to work, but it does! Real-world example: A company has many point-of-sale systems placed at external partner companies. Guess what? They have legal fights going on about real money. The question debated is whether the POS software itself worked correctly. Digital signatures wouldn't help in this situation since the partner would simply claim that what was displayed on screen was different from what was signed by the software. (They have a lab where each and every version of the software is installed for testing by assessors.) Also when signing a contract by hand I usually get a physical copy of it which I can archive. That's not the case when doing web-signing. That's another important flaw of that scheme. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. [..] There are some fundamental issues with this stuff, such as, how does the user know what he's being asked to sign? How does he know that he's not being asked to sign a document conveying the deeds for all his real property to the web site owner? In some countries where digital signatures have the full force of law, just like a real signature, this could be a serious issue. Yupp. Glad you already wrote what I wanted to say. When thinking it to the end it even gets more messy than the S/MIME stuff. Especially since web designers and marketeers come into the way when talking about the user interface. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. The German signature law and the accompanying directive tried to protect the user by specifying minimal requirements for the signature process and components used. I guess that's what Anders calls (German nfluences...) monstrosity in his other posting. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: Nelson Bolyard wrote: Eddy Nigg wrote: On 11/19/2008 05:52 PM, Anders Rundgren: In the meantime, wouldn't it be of some value if Mozilla tried to satisfy a PKI- related activity that in number of users, already is much bigger than S/MIME, i.e. the concept of Web Signing? What is this supposed to be? Perhaps I missed it? I think this is a reference to the action historically called form signing (or more accurately form post signing) in Mozilla. It's a way to sign the data being sent in to a web server with the user's private key, as the data is being sent. Mozilla implements this with a javascript extension known as crypto.signtext. I think IE implements it with an ocx (an Active-X module). Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? Yes, more or less. There are several approaches in proprietary products. With Netscape's form signing the web application had to generate simple HTML from the form content which was displayed in a separate popup-window. I vaguely remember that the HTML displayer was restricted to avoid white on white or similar faking. The simple HTML blob was then signed (PKCS#7). There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No. This is a business problem not a tech problem. Exactly! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? The crypto.signtext() function is given a text string, and the browser UI pops up a dialog box that invites the user to read the text, and then if the users agrees with the content of the text, they are invited to sign the text with their digital certificate. The signed text is then placed into a form field, and is returned to the server on POST. The server can then ask the question is this text the text I wanted signed?, followed by is this text signed by the user using a cert trusted by the CA(s) I have in my hand?. For example, the server generates a piece of human readable text along the lines of: The following claim note has been APPROVED for payment: Claim note: Y / XYZCN / CARGO - Breakage Paid To: Z Date: 01-Sep-2008 Amount: (X) VAT: X Total: (X) If the user agrees with the text, they sign it. If they disagree with the text, they don't. In this particular application, they can sign a new declaration that withdraws a previous declaration, so they can change their mind. The text between the inverted commas represents the complete and only thing the user is agreeing to. If it doesn't appear in the text block, it doesn't get signed. There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. In law in the jurisdiction in which the application above runs, a digital signature has the same legal weight in law as a paper signature. A checkbox with the words I agree is not a signature. You can define in law a contract which becomes enforceable as soon as somebody performs a specific action. That action might be parking your car in a parking space (and in the process you agree to the terms on the sign at the entrance to the car park, if you disagree, don't park there), or that action might be opening the seal on some packaging (if you open this package you agree to the following software agreement, if you disagree, don't open the package), or that action might be a checkbox saying I agree (if you disgree, don't click on I agree). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Responding to two at once! Graham Leggett wrote: Anders Rundgren wrote: I also understand your worries regarding what to sign and I would be very dishonest if I said I have solved it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the viewer works as expected. Now, why don't I feel that this is a huge limitation? First a legal issue. Based on *actual* court cases you can indeed be convicted based on IP addresses if you are found downloading forbidden data. I.e. digital signatures are simply a stronger evidence. Technically correct, but it doesn't suggest a conclusion that it will work. Practically, we might need something that looks like a signature on a document, and -- correct me if I am wrong -- I didn't see it in the tax invoice demo. I'm thinking here of some document that is sent to the user with some token attached that says you signed this ... but it could be anything. Now onto Graham's surprising response! I suspect you have spent too long in the fluffy who cares world where when presented with an agreement to sign, you just blindly click on the accept button trusting that the agreement that was never read contained nothing harmful to you in any way. Seems like we've all spent some fluffy time :) Having designed a system that includes web signing using crypto.signtext() for an insurance company to handle claim approvals, I can tell you that the primary question of the business people who used the system was just what are we signing exactly?. OK, that's interesting but equally worrying that the business people were asking that question, above all others. If so, this would suggest to me that your business people had spent too long in the fluffy do what lawyers say world, and had forgotten they had a business to run? Lawyers have a particularly perverse reason to say what they are saying just what are we signing exactly, and business people would do well to learn why that is. Did your business people ask about the evidentiary aspects? Disputes? Contracts? Basis in law? Risks? Fraud? Document management? Customer relations? Work-flow? In the case of crypto.signtext(), the end user is presented with a piece of human readable text, and the end user can choose to sign or not sign that human readable text, as appropriate. That user readable text is the beginning and end of what they are asked to sign. OK, and how do you show afterwards that they signed it? I did a little googling and found something called the Netscape verification tool ... I would hope there is more to it than that, to put it mildly. Signing a form is completely meaningless, because the user is not given a full, complete and unambiguous entity for them to sign. completely meaningless would be a strange way to describe the reality of how most people agree to stuff, including those people who dispute the agreements (a.k.a. the courts). Then a practical issue. If a crooked site asks you to sign a form that in some way is camouflaged (using overlaid HTML) into something else, the question is really what the crooked site can do with that unless the crooked site actually is a genuine representative of your government, bank, or employer. Seriously, if you cannot fathom the security risk posed by someone asking you to sign an agreement when you cannot see the full agreement you are signing, then you seriously should not be trying to design any secure systems at all. Seriously. Seriously, it is a business risk. It isn't a security risk unless the business says it is a business risk, *and* they accept the security solution. Anders is correct, you are wrong. If you approach this problem as if security can solve it, you're in trouble from day one. Seriously. It is a common mistake to grasp onto an issue that is amenable to a bitsbytes treatment, and then ramp it up from an issue to a security risk to a business risk to an imperitive. This is the typical mid-1990s hubris of all things being solved by crypto. Those systems, so designed, pretty much all fell to basic failings. C.f., phishing. Or didn't achieve any reasonable deployment. C.f., S/MIME. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: OK, that's interesting but equally worrying that the business people were asking that question, above all others. If so, this would suggest to me that your business people had spent too long in the fluffy do what lawyers say world, and had forgotten they had a business to run? Lawyers have a particularly perverse reason to say what they are saying just what are we signing exactly, and business people would do well to learn why that is. Did your business people ask about the evidentiary aspects? Disputes? Contracts? Basis in law? Risks? Fraud? Document management? Customer relations? Work-flow? Yes they did. I think you underestimate just how well recognised digital certification is in legal systems around the world. Internet ecommerce is not new, and digital certification is not new to lawyers or the legal system either. OK, and how do you show afterwards that they signed it? I did a little googling and found something called the Netscape verification tool ... I would hope there is more to it than that, to put it mildly. Google more. We use the Bouncy Castle libraries to verify the signature on the text, because our system is inherently Java based, but you could use any other crypto library, including NSS. None of this stuff is new, crypto.signtext() has been around for ten years or more, and the crypto libraries that support it, longer than that. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On Nov 19, 2:27 am, Eddy Nigg [EMAIL PROTECTED] wrote: On 11/19/2008 01:59 AM, kgb: Hi Kevin, WISeKey has made some changes to its practices, since the last public discussion period. I'm glad to hear that! Can you point to what specifically has been changed since then? Probably the most important change in stated practice, is that it is reflected that every CA is audited at least once annually. This is the case for all active CAs. BlackBox Subordinate CAs are restricted to issue certificates for domains that are owned by the company that is responsible for them, quite unlike the typical root signing done by other companies. How are email certificates validated beyond that? Are they validated - or is it a catch-all verification for all email certificates under the respective domain name(s)? Email certificates are also restricted to the organisation's domains. We include a Constraint in the Issuing CA itself, preventing the same CA software to issue certificates that don’t comply with this Domain Restriction (web, email, User Principal Name, etc.) The company database (such as existing HR, or IDM) of organisation, with details of the organisation's users, including their email addresses, is the principal source of data for certificates. Bounce back email verification procedure proving access to the email account is also accepted, but this is inefficient in the enterprise context, as the enterprises IT systems are aware of the email address book. In addition other identity data in the certificate must come from a verified source, e.g. HR database of identity data that is well- maintained and was created based on face to face or direct verification of the person. BlackBox subordinate CAs are also audited onsite at least once annually. By whom? I remember from the last discussion that you weren't performing on-site visits or only randomly, download of the software and CA keys were provided via Internet download. Currently it is WISeKey that audits all our CAs, we review the CAs at least once annually, or more regularly as we are more often present on some client sites. In addition to the controls we place on issuance, we also place monitoring controls and obtain regular reports. All CA keys are generated within accredited HSMs. No CA private Keys are provided via Internet download - this has never been the case. CA keys have, and are always generated within a protected HSM. There have been changes to the policies and practices. The CIDClassed document is a summary of WK practices and certificate classes. OK, I will examine this document further then... WISekey's products do not circumvent the audit requirement. WISeKey's products conform with the basic requirements of the Mozilla CA policy. WISeKey subordinate CAs in the BlackBox category can only issue certificates containing domain names that have been validated as being owned by the customer. These CAs are audited physically onsite, there are technical controls preventing the issuance of certificates containing any other domain name, and there are additional monitoring controls. Did your auditor perform random verifications of those visits, verify some of these installations and the technical controls? You don't have to answer this question, but it would be nevertheless interesting to understand the extend of the audit performed. Our auditor has reviewed all of our policies and practices, controls, and has accepted them as being sufficient. The auditor reviews audit information from all CAs, and can request to visit any or all CA sites at any time. Which ones, how many, they have done for the last year, audit etc., is and remains confidential. What are your requirements and controls concerning physical and logical access to the system(s)? (pointer to the CPS section is fine) For systems hosted in our DC, section 4 of the Issuing CA CPSs in the repository applies (www.wisekey.com/repository). For TrustCenter (BB) CAs - those CAs on customer sites, the relevant excerpt is as follows:- 4.PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS 4.1. Physical Controls for the Issuing CA The hardware and software for the Issuing CA is maintained on-line in a secured facility with perimeter security and enforced internal access controls. 4.2. Procedural Controls No member of staff is allowed to gain physical access or operate any component of the Issuing CA without the presence of other designated members of staff who have the skills required to confirm that no unauthorized or inappropriate actions are conducted. Procedures are defined and documented for all operations upon the Issuing CA. Operating procedures are regularly reviewed in the light of new operational requirements. 4.3. Personnel Controls All ISSUING CA OPERATOR staff involved in the operation of the Issuing CA is subjected to background checks and vetting according to ISSUING CA
Re: WISeKey root inclusion request (re-start public discussion)
Hi Eddy, On Nov 19, 3:14 am, Eddy Nigg [EMAIL PROTECTED] wrote: Frank: TheWisekeycase could be where we might draw the line. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); - name constraints in certificates are working as expected with NSS andMozillasoftware *; - reasonable verifications are performed of the sub-ordinate certificate owner; I tend to suggest to exclude the audit requirement for this specific case. It should however represent the line between the other cases. * One thing I'm not sure about is concerning S/MIME certificates and their verification requirements. And do name-constraints work with S/MIME? Name-constraints work on the level of the CA, and this is what we rely on together with the audit and monitoring tools. The CA looks at its certificate, and won't issue a request SMIME or otherwise that violates the name constraints. Kevin (fromWisekey): Why is a sub-ordinate CA certificate needed for this product, if it's limited to a certain set of domain names? Can't the same be achieved by simply issuing from a general sub CA under the control of the parent CA? What are the differences for the customer (I mean, it doesn't really matter if a site certificate or email certificate is issued from a sub CA under the control of the parent CA or from a different sub CA under the control of the owner. In the end of the day there may be only a certain set of domain names for the same set of web sites)? We offer both types of delivery. We have many managed PKI customers. However some agencies don't wish their ID information to leave their premises, or to cross national borders; or desire to have closer integration with the ID lifecycle management software and internal directory, which is far easier and more efficient with the BlackBox system, and its also far more cost effective especially in large user populations. There are also other reasons, but those are probably the most important. Nelson: Do name-constraints work as expected with NSS and Firefox/Thunderbird etc.? I didn't had a chance to test this ever...Are there some test cases with correctly and wrongfully issued certificate which would demonstrate the correct functioning? What about S/MIME certificates? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Graham Leggett wrote: Ian G wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? The crypto.signtext() function is given a text string, and the browser UI pops up a dialog box that invites the user to read the text, and then if the users agrees with the content of the text, they are invited to sign the text with their digital certificate. The signed text is then placed into a form field, and is returned to the server on POST. The server can then ask the question is this text the text I wanted signed?, followed by is this text signed by the user using a cert trusted by the CA(s) I have in my hand?. For example, the server generates a piece of human readable text along the lines of: The following claim note has been APPROVED for payment: Claim note: Y / XYZCN / CARGO - Breakage Paid To: Z Date: 01-Sep-2008 Amount: (X) VAT: X Total: (X) If the user agrees with the text, they sign it. If they disagree with the text, they don't. In this particular application, they can sign a new declaration that withdraws a previous declaration, so they can change their mind. The text between the inverted commas represents the complete and only thing the user is agreeing to. If it doesn't appear in the text block, it doesn't get signed. Thanks for the explanation! There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. Wow, that is nice. So the java script is running the crypto access completely separately from the HTTPS stuff? OK, then, how does the browser manage the signed text? Store it somewhere? Verify it somehow? Without some sort of management, I'd worry that the system would not survive scrutiny. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. In law in the jurisdiction in which the application above runs, a digital signature has the same legal weight in law as a paper signature. OK, and is it a technologically neutral law? If so, then a checkbox / agreement will work fine. Or is it the European qualified thing, in which case, we enter a world of pain? Or, even worse, in Germany, where they take the qualified thing seriously, and suffer inordinately. A checkbox with the words I agree is not a signature. A check in a box can be an intent to agree, the check is a mark of agreement, ergo it is a signature, and of course digital. What it is not is a manuscript signature. The differences are subtle, sure, but important. You can define in law a contract which becomes enforceable as soon as somebody performs a specific action. That action might be parking your car in a parking space (and in the process you agree to the terms on the sign at the entrance to the car park, if you disagree, don't park there), or that action might be opening the seal on some packaging (if you open this package you agree to the following software agreement, if you disagree, don't open the package), or that action might be a checkbox saying I agree (if you disgree, don't click on I agree). Right, precisely. Checkboxes can do agreements fine. Whether you need more than that depends on the circumstances, somewhat. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote: This requires a client-certificate HTTPS connection to the webserver to make it happen? No, this can happen over an insecure http connection. The connection between the browser and server has nothing to do with the crypto.signtext() function. Typically, you would probably want to run it over an https connection, but the point is there is no relationship between the signing of the text and the transport over the network. There is also no relationship between the CA used to trust the server connection, and the CA used to trust the user's signature. Wow, that is nice. So the java script is running the crypto access completely separately from the HTTPS stuff? Yes. OK, then, how does the browser manage the signed text? It just sends the PKCS#7 blob along with the form. The server-side application has to validate the signature and parse the input data from the simple HTML which was signed. Store it somewhere? Verify it somehow? Nope. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Slamming Web signing
Have you looked into this paper? http://webpki.org/papers/wasp/wasp-faq.html Unfortunately I believe there are too many uncoordinated views on this matter to return a fruitful discussion but let me tell you how it works in Sweden: In Sweden all the banks supply proprietary signature clients that essentially have the same (limited) capability as crypto.signText (). Now to the fun. Since a tax declaration is a fairly complex document, a text/plain view is rather useless. The tax department's solution is brilliant. In the signature text/plain window they show an XML version of the tax declaration while the user is presented a nice HTML version in another browser window. Naturally there is no cryptographic binding between the HTML view and the XML (which is signed). Anyway, Swedish security experts (-AR) claim that this is the optimal version of digital signatures. WYSINWYS. This situation was one of the inspirations to the WASP concept. Now over to some of the topics: Michael Ströder wrote: I also understand your worries regarding what to sign and I would be very dishonest if I said I have solved it. In fact, my design doesn't even address this issue (!) except that if of course builds on the assumption that at least the viewer works as expected. But it's the main issue! If you don't address this it's simply worth nothing. And you're bashing S/MIME use. Ah well... I expressed this wrongly. You MAY use a trusted viewer that would abort or warn suspicious requests. My implementation doesn't because of the fact that I consider it unnecessary for the primary target which is governments, banks, and in-house work-flow. From a Platform point-of-view it is also about 30 Mb (The Austrian solution which is umständlish) versus a 0.5 Mb increase of the browser executable. Real-world example: A company has many point-of-sale systems placed at external partner companies. Guess what? They have legal fights going on about real money. The question debated is whether the POS software itself worked correctly. Digital signatures wouldn't help in this situation since the partner would simply claim that what was displayed on screen was different from what was signed by the software. (They have a lab where each and every version of the software is installed for testing by assessors.) As you say, there is no solution to the problems you just described so why would I or anybody else spend time on that? Also when signing a contract by hand I usually get a physical copy of it which I can archive. That's not the case when doing web-signing. That's another important flaw of that scheme. I have heard that many times but Web Signing is not S/MIME, it is better :-) Good web applications always offer you a receipt that tells what the service thought the deal was about and when it received it. The receipt may be delivered on-line or through e-mail or as it typically is, both ways. Try the on-line version: http://upi-using-service.webpki.org/IncomeDeclaration click the I icon to get proper PIN when asked to sign or authenticate. OK, then, how does the browser manage the signed text? It just sends the PKCS#7 blob along with the form. The server-side application has to validate the signature and parse the input data from the simple HTML which was signed. This is exactly how WASP does NOT work. The server generates static HTML (and calculates hashes) and sends that to the client who signs the HTML and returns the signature only. Very simple, very efficient, and completely universal with respect to media type. Yes, could sign Flash if you felt that this is what the market wants :-) Graham Legget wrote: Signing a form is completely meaningless, because the user is not given a full, complete and unambiguous entity for them to sign. I don't understand the meaning of the second line. BTW, in WASP you don't sign forms, you sign static views. Seriously, if you cannot fathom the security risk posed by someone asking you to sign an agreement when you cannot see the full agreement you are signing, then you seriously should not be trying to design any secure systems at all. Seriously. It's really not that simple. Nothing prevents a signature requester not including the fine print or write the request in such a way that they user is tricked. Even producing a very long document is a way to screw the poor user. That is, if the user is dissatisfied, it is up to the service to replicate the situation and if that shows that the service actually has erred one of the purposes of signatures has indeed been met. Anders___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
Eddy Nigg wrote: The Wisekey case could be where we might draw the line. I'm not sure exactly which message (of mine or someone else's) you're responding to. In any case I don't think there's a bright line between the various scenarios involving independently-operated subordinate CAs. However in general I would look at the extent to which the subordinates are operating within a restricted context. E.g., they're associated with a single enterprise, they're technically and contractually constrained to operate within a relatively small set of domains, etc. At the other end of the spectrum the subordinates are essentially general-purpose public CAs, issuing certs to multiple customers, for arbitrary domains, etc. Based on the information available to us, WISeKey's subordinate CAs seem to be at the restricted context end of the spectrum. Provided that - there is a *good compelling reason* for using sub-ordinate certificates in first place, limited to the domains under the control of the owner (via name-constraints) and with reasonable controls in place (like annual site visits, proper CA key generation, distribution and storage); Based on what Kevin Blackman wrote, one major reason for the approach taken by WISeKey is the desire of customers to keep subscriber information within enterprise boundaries and/or national borders. Given the complexities of, e.g., privacy regulations in the US vs. the EU vs. other jurisdictions, this seems to me a good reason for an enterprise to operate its own subordinate CA as opposed to, for example, just acting as a Registration Authority for a subordinate CA operated elsewhere. - name constraints in certificates are working as expected with NSS and Mozilla software *; Whether certificate-based name constraints are properly working or not, I think this is more our problem than the CA's problem, provided that the CA's cert don't cause actual technical errors in NSS/Mozilla. If a CA is implementing technical measures we consider sound, then I think they have done what we expect and require. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote, On 2008-11-20 07:53: Graham Leggett wrote: Having designed a system that includes web signing using crypto.signtext() for an insurance company to handle claim approvals, I can tell you that the primary question of the business people who used the system was just what are we signing exactly?. OK, that's interesting but equally worrying that the business people were asking that question, above all others. Really? It seems to me that ANY prudent person would ask that question when asked to sign anything. I know, lots of people will sign anything they are asked to sign, and most of them do not suffer, because most people who ask for signatures are not trying to achieve evil ends. But I read every document that I am asked to sign in its entirety, and I would be stunned if a person who is asked to sign a document with a company issued credential would not ask the same. There are many places in the world where you don't want to have signed a document agreeing to certain things. You don't want to sign something critical of the government in China. You don't want to sign something sympathetic to radical Islam in the USA. You don't want to sign something taking sides in one of the ancient disputes in regions such as the former Yugoslavia or Czechoslovakia, in may parts of the world. People don't need to be lawyers to be aware of the risks of blindly signing things. In the case of crypto.signtext(), the end user is presented with a piece of human readable text, and the end user can choose to sign or not sign that human readable text, as appropriate. That user readable text is the beginning and end of what they are asked to sign. OK, and how do you show afterwards that they signed it? I did a little googling and found something called the Netscape verification tool ... I would hope there is more to it than that, to put it mildly. IIRC, crypto.signtext produces a document that is in an IETF standard format, known as Cryptographic Message Syntax (CMS, originally known as PKCS#7), which is also the signature format used in S/MIME. There is lots of software in the world that can read such documents and verify the signatures. Seriously, it is a business risk. It may also be a personal risk. It isn't a security risk unless the business says it is a business risk, *and* they accept the security solution. My employer has a LONG list of acceptable business practices. Employees are forbidden to do a whole bunch of things, including making agreements with parties taking positions against other parties. It's surprising how many people will try to get you to sign a statement condemning certain nations (or religions or ethnicities) of the world, as a condition of doing business with them. My employer promotes the use of digital signatures, and it's particularly important not to sign something like the documents to which I've alluded above. I don't think these requirements of my employer are exceptional. Anders is correct, you are wrong. I think such statements are supposed to begin with the word Fiat. If you approach this problem as if security can solve it, you're in trouble from day one. Seriously. So, you're saying that making the content of the document being signed visible to the signer is to be in trouble, and not a contribution to the signer's security? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/20/2008 10:21 PM, Frank Hecker: Eddy Nigg wrote: The Wisekey case could be where we might draw the line. I'm not sure exactly which message (of mine or someone else's) you're responding to. I refereed to the general discussion about sub roots. In any case I don't think there's a bright line between the various scenarios involving independently-operated subordinate CAs. On the other hand I think we should be clear in relation to the requirements placed upon the CAs. We should define them as clearly as possible in order to allow CAs prepare accordingly. Based on the information available to us, WISeKey's subordinate CAs seem to be at the restricted context end of the spectrum. Yes. Additionally one of the major concerns have apparently been corrected! As I mentioned earlier, I think that name-constraints and mandatory self-auditing by the CA seem to me sufficient. Based on what Kevin Blackman wrote, one major reason for the approach taken by WISeKey is the desire of customers to keep subscriber information within enterprise boundaries and/or national borders. Given the complexities of, e.g., privacy regulations in the US vs. the EU vs. other jurisdictions, this seems to me a good reason for an enterprise to operate its own subordinate CA as opposed to, for example, just acting as a Registration Authority for a subordinate CA operated elsewhere. I think that argument is somewhat far-fetched as the customer could work with a local authority instead. As I understood the subscriber information have to be disclosed to the CA anyway (monitoring, evidence and audit trail etc), hence I'm not really convinced. Integration into enterprise infrastructure however seems to me more logical... Whether certificate-based name constraints are properly working or not, I think this is more our problem than the CA's problem, provided that the CA's cert don't cause actual technical errors in NSS/Mozilla. If a CA is implementing technical measures we consider sound, then I think they have done what we expect and require. In this case, name-constraints are clearly part of the policy regulating those sub CAs and in my opinion the most convincing argument in favor for self-auditing of those installation as opposed to the general audit requirement. If name-constrains don't work as expected, an inclusion will have to be conditional on implementation. There shouldn't be a situation where the issuance of the sub-CA is based clearly on name-constraints regulation and NSS can't support it. Right now it's a hypothetical concern because I don't know what the situation is. Hopefully Nelson or somebody else will provide this information within reasonable time. (And I should add that if there problems in NSS that need additional work to fix them, the Mozilla Foundation does have the ability to fund such work.) Great! -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: WISeKey root inclusion request (re-start public discussion)
On 11/20/2008 06:34 PM, kb: Probably the most important change in stated practice, is that it is reflected that every CA is audited at least once annually. This is the case for all active CAs. Kevin, thanks for clarifying this. It indeed was one of the concerns raised last time. The company database (such as existing HR, or IDM) of organisation, with details of the organisation's users, including their email addresses, is the principal source of data for certificates. OK. Bounce back email verification procedure proving access to the email account is also accepted, but this is inefficient in the enterprise context... That's why I asked... ;-) In addition other identity data in the certificate must come from a verified source, e.g. HR database of identity data that is well- maintained and was created based on face to face or direct verification of the person. Excellent! Currently it is WISeKey that audits all our CAs, we review the CAs at least once annually, or more regularly as we are more often present on some client sites. In addition to the controls we place on issuance, we also place monitoring controls and obtain regular reports. Last question: Are there any sub CAs besides the blackbox product (with name-constraints) which are external to your physical infrastructure? I think there is not, but can you confirm that? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Ian G wrote, On 2008-11-20 06:04 PST: Nelson Bolyard wrote: Um. So these tools organise a signature from a client cert over the text in the form text box, and then post the signature up to the server? Well, I can only speak for what Mozilla browsers do. They generate a document that contains the signed text and the digital signature and the certificate chain with which the digital signature can be verified (or repudiated), in the CMS format. That document is sent. There doesn't seem to be any standard for a way make this work that is common to all browsers. NSS provides the necessary crypto code. This requires a client-certificate HTTPS connection to the webserver to make it happen? It's completely independent of https. The browser *may* use the same cert for signing a document as for https client auth, or there may be no https client auth at all (and indeed, no https at all). The signed document can be verified on its own without regard to the channel through which it was sent. It's essentially a little S/MIME message, minus the MIME. :) (SMIME = MIME + CMS) What's missing is the definition of the way (syntax) by which to invoke it in the browser. If I recall correctly, Anders has proposed something for that purpose, and perhaps he has developed some software for that purpose. Right, Anders pointed me to this in private email: I wrote a lengthy response about how/why some proposals get adopted and widely deployed in the web, and others do not, but it's too long for this thread. Maybe I'll send it separately in another thread. I'm personally wary of efforts that push to make it possible for users to make such legally effective signatures without solving the problems of how to protect the user. Plus, they are generally not necessary. A digital signature isn't a signature, whereas a checkbox with the words I agree is. Where you live, maybe. In other parts of the world, a digital signature is a signature (the strongest form, in fact), and some server's log file claiming that the user checked the checkbox here is worthless. Well, my first thought was: this can't work, for all the normal reasons why digital signatures don't work. My second thought was, gee, I need it in a project I'm working on. Oops! Hmmm... I wonder what my third thought will be... Me too. :) Seriously though, I can see lots of applications for it, but the infrastructure required makes this less of a tech concept and more of a legal / document management management concept is missing in most contexts. This is a business problem not a tech problem. Clearly it is a problem in both spaces simultaneously. Clearly, the ability to produce wonderful signed documents with lots of wonderful properties (effectively unforgeable, alterations are all detectable) is useless if no-one puts them into use (witness both S/MIME and PGP), but by the same token, without the technology to provide some resistance to forgery and alteration, (or even replay/playback), the business world will not take the risk of using technologies that produce documents that are easy to forge, alter or replay (in contexts where documents are of sufficient value that others may be tempted to engage in such things). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Web signing?
Hi Nelson, welcome to this fun debate :) Nelson B Bolyard wrote: Ian G wrote, On 2008-11-20 07:53: Graham Leggett wrote: Having designed a system that includes web signing using crypto.signtext() for an insurance company to handle claim approvals, I can tell you that the primary question of the business people who used the system was just what are we signing exactly?. OK, that's interesting but equally worrying that the business people were asking that question, above all others. Really? It seems to me that ANY prudent person would ask that question when asked to sign anything. Maybe they do; as you and I agree, many people do not. That includes many businesses. There is good reason for this. One example: when the guy comes in a truck and hands you a package, and asks you to sign his clipboard, there is no reason to ask what am I signing. It is more or less for delivery, with the more including some agreement you weren't shown, and the less for protection of the driver in case of loss. There are many places in the world where you don't want to have signed a document agreeing to certain things. You don't want to sign something critical of the government in China. You don't want to sign something sympathetic to radical Islam in the USA. You don't want to sign something taking sides in one of the ancient disputes in regions such as the former Yugoslavia or Czechoslovakia, in may parts of the world. People don't need to be lawyers to be aware of the risks of blindly signing things. You misunderstand my point. When I say, business people looking at agreements and systems of agreements should not ask the question what exactly am I signing as the primary question, I am not offering a wholesale licence to run around and sign people up for the next jihad. Instead, I am pointing out that the requirements for a signing application should be driven by the business needs, and that isn't one of them. (Although, the reason it isn't is quite perverse and obscure.) It may be a personal need or a lawyer's need, but that simply isn't at issue. In the case of crypto.signtext(), the end user is presented with a piece of human readable text, and the end user can choose to sign or not sign that human readable text, as appropriate. That user readable text is the beginning and end of what they are asked to sign. OK, and how do you show afterwards that they signed it? I did a little googling and found something called the Netscape verification tool ... I would hope there is more to it than that, to put it mildly. IIRC, crypto.signtext produces a document that is in an IETF standard format, known as Cryptographic Message Syntax (CMS, originally known as PKCS#7), which is also the signature format used in S/MIME. There is lots of software in the world that can read such documents and verify the signatures. OK, this was also pointed out in various mails, so to answer them all: Of course, we are all sure that a PK digsig operation produces a signature over a hash over a document, and if I download blah-blah software and run some crypto-whizz-bang transformation over it, I'll be able to claim some wonderful thing about mathematics. We all know about PKs. That wasn't my question. Here's my question again: How do you show any person afterwards that the person signed it? I mean: how does Alice look tomorrow in this system to see what she signed? Next year? How does Bob look next year to see what Alice signed? How does Trent, some random third party like a judge? The system above seems to have none of that. In analogous terms, it seems that we have invented a new form of ink, but because the business controls the penpaper, and has not provided it to the user, we do not have the essence of signing. That system has yet to evolve to the point where it makes a serious agreement useful or sustainable. Let's take a stab at what it would take to do that. Some requirements: a. Alice can check what she signed for a long time b. Bob can check what Alice signed for him for a long time c. Trent can be presented by either Alice or Bob with a signed doc. (Note the oddity that there is no d.: anyone can check the signature is valid cryptographically.) So, to meet that requirement, it would seem that the crypto.signtext() function should also cache the entire document + signature (bound together, maybe that's CMS) in some place next to the user's PKs. Then, in the Key Management section of Firefox, there should be a show my signed docs. Add some sugar like export, print, new. Duplicate for Bob. Now we have a system. (Note that one of the important points of a signing protocol is that it memorialises the document. I'm afraid I am travelling at the moment, and can't look up all the other points.) Seriously, it is a business risk. It may also be a personal risk. Not denied, although this is not as important. Firstly, it is the
Trouble importing test root certificate
Hi folks. I'm having some trouble using CERT_ImportCerts. A minimal demo of the problem is at http://kegel.com/cert-import-demo.cc All this does is take a base 64 cert, decode it, and import it. I have verified with the sequence $ mkdir ~/.netscape $ certutil -N $ certutil -A -n foo -t p,p,p -i ~/root_ca_cert.crt $ certutil -L -n foo that the cert embedded in this source file looks reasonable to my untrained eye. Also, since Issuer: O=Cert Test,L=Mountain View,ST=California,C=US,CN=Test CA is the same as Subject: O=Cert Test,L=Mountain View,ST=California,C=US,CN=Test CA it should be recognized as a root cert, right? First problem: Decoding fails because NSSBase64_DecodeBuffer appears to barf on the trailing ---END CERTIFICATE---. Am I using this function properly? It seems to have code to skip trailing garbage, but evidently it's too fragile to ignore this common trailer. Change #if 0 to #if 1 to work around this. Second problem: Importing fails. The error is -8187, SEC_ERROR_INVALID_ARGS Stepping through the code, I think I see it first not believing it's a root cert, and then complaining that it doesn't recognize the authority (no surprise there, if it doesn't think it's a root cert). Can somebody point out where I'm going wrong? Thanks! - Dan ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Trouble importing test root certificate
On Nov 20, 4:23 pm, DanKegel [EMAIL PROTECTED] wrote: First problem: Decoding fails because NSSBase64_DecodeBuffer appears to barf on the trailing ---END CERTIFICATE---. Am I using this function properly? It seems to have code to skip trailing garbage, but evidently it's too fragile to ignore this common trailer. Change #if 0 to #if 1 to work around this. Wan-Teh says CERT_DecodeCertPackage is the thing to use there, and it appears to know about END CERTIFICATE. So ignore my first problem... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS DB migration problem
Wolfgang Rosenauer wrote: Hi, Hans Petter Jansson schrieb: This database only fails to migrate if the target database was not already created by another, successful merge, though. I think you're saying that the failures only occur if the target (cert9) DB doesn't already exist when your program is run, but does succeed if the target is already a legit cert9 DB. Is that what you're saying? That would not surprise me. I think that the function you're using, NSS_InitWithMerge, does assume that the target DB already exists. Almost. I'm saying that if the database fails to migrate the first time, and leaves an empty database, then subsequent merges to that database also fail. However, if the first merge is successful (creating the database and populating it), then subsequent merges always work. I have a small sample size, though, since I don't have (nor want, really) direct access to other users' databases. It looks like Wolfgang found the problem, or at least a problem, in the Firefox' password manager thread, so I'm going to test using a normal NSS_Init() to create the database if it doesn't already exist, and see if that works. Thanks, Wolfgang :) I _think_ the problem when creating a new database (if one doesn't already exist) using NSS_Init() could be that the internal token (SDR) is created and people will never be able to read their passwords again even after a merge? I think what should be done is to mimic exactly what certutil -L -X -d sql:. is doing for the initial creation of the database? In the single cert8/key3 update to cert9/key4 (as opposed to a merge update where you are merging from cert8/key3 to a cert9/key4 in a shared location) case, which is what we are talking about here, there is a 2 step update. The second step requires a password. The code is supposed to know if the update has only half completed (I had some problem with early version of the shared DB code), where the databases are created, but the tables have not been. When it comes time to do the actual migrate, the tables are then created. If this is the case that's failing, we can simulate it with certutil as follows: Start it a dbm database with a password. certutil -L -X -d sql:. This command does not require a password, so the databases will only partially update (databases are created, but not populated). certutil -K -x -d sql:. supply the password This should successfully update the database. I've just tried this and it failed. So this looks like a good test to reproduce the problem. I'll attach it to the bug. bob Wolfgang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Trouble importing test root certificate
On Nov 20, 6:14 pm, Nelson B Bolyard [EMAIL PROTECTED] wrote: When I change the sample program so that cert_text no longer contains the -BEGIN and -END lines, and so that the value assigned to len no longer includes the trailing NUL character, then when I run the program, it outputs: Loaded certificate! Aha. Thanks! - Dan ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: how to decrypt with pubkey without pkcs1 padding things
Robert Relyea wrote: Ken wrote: 2008/11/15 Robert Relyea [EMAIL PROTECTED]: NZzi wrote: Robert Relyea wrote: NZzi wrote: hi all: I want to use private key to encrypt a message, and decrypt with public key. Are you encrypting data or a symmetric Key? Most of the nss code that does these operations does so on actual symetric keys (which are then used to do additional encryption/decryption/macing). In that case they are using the PK11_PubWrapSymKey() and PK11_PubUnwrapSymKey(). If i use symmetric key to encrypt a license and use private key to encrypt the symmetric key, other people can have my public key. Yeah, it's an unfortunate name. The Pub in PubWrapSymKey means 'Public Key Cryptography not PublicKey. It's really the private key. It was written before we started standardizing on separating Public and Private in the function name. but i must guarantee the integrity of license and forbid it from regenerating or modifying. No matter what key(public or private) is used to wrap the symkey, if someone hack the program to get the unwrapped symkey(e.g. from memory), he can modify and regenerate the license to pass the validation. So i just want to use private key to encrypt the license, decrypt and validate it using public key. OK, so you are doing a signing operation, not an key exchange or encryption. (the symetric key only applies to the decryption issue). In doing crypto, it's important to understand what your high level goal before you can apply the appropriate primitives. In this case it sounds like you aren't really making data unreadable, you are simply making sure the data is the correct data (that is the license is valid). The reason I don't use SGN_*() is I need recover the content of license. I tried the PK11_VerifyRecover(), but got 8192 error, So I'm not sure PK11_VerifyRecover() can recover the content of license signature, signed by PK11_Sign(private_key,...)? Typically you include the data you are signing in the clear along with the signature. The license content can't be a secret, or your scheme is broken (anyone can get it if you 'encrypt' it with your private key). If you just use the RSA encrypt, you are definitely tying yourself to RSA (no possibility of using some other signing algorithm, which requires you to possess knowledge of what it is you are trying to sign before you actually verify). If you are trying to match some existing system, then you are pretty much stuck with RSA anyway, but if you are building this on your own, then consider including the data outside the signature. You'll thank me later;). That being send, PK11_VerifyRecover should work. The most likely reasons for it not working include: 1) the public key you decrypt with doesn't math the private key you encrypted with, 2) the signed data is corrupted in some way. What does your code sample look like? yeah, in order to get the real reason of the problem, i had to compile NSS from source and debug my program with NSS code, then i found why i got 8192 error. It's because the length thing of data and signed data. I think Chang's current work on doc is great, a detailed Docs about NSS API(each level, including PKCS#11, Crypto Wrapper, and etc) will help people like me(know the basic cryptography knowledge, but not good at it) a lot. anyway, thanks very much bob ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
