Re: How-to guide for email encryption
IM[NS]HO, S/MIME encryption using PKI is one of the biggest security farces ever. Even the use-case is often wrong. Somebody representing "e-Health" once described for a big audience how S/MIME encryption could be used to exchange private medical information between a doctor and a patient. But medical treatment is a collective effort and it would be pretty wrong if the doctor was the only party who knew what medication or HIV test results the patient got. Regarding the guide, I believe that e-mail encryption would be fairly common if it had been (generally) based on using a shared secret, because passwords are easier to use than PKI (for encryption NB). That the secret actually is shared is a big advantage as well if you are involved in somewhat dubious activities like cheating on your spouse with a work-mate, trying to sell your company to a competitor, or if you are just an ordinary crook with a network :-) Anders - Original Message - From: "Paul Kinzelman" <[EMAIL PROTECTED]> Newsgroups: mozilla.dev.tech.crypto To: Sent: Tuesday, November 18, 2008 07:15 Subject: How-to guide for email encryption I created a file to help a newbie get email encryption going. It's what I wish I could have found when I was stumbling through the process myself, and with the help of an expert in this newsgroup (many thanks to you, you know who you are :-), I've created a document for others. Feel free to pass the link around and to comment and suggest enhancements. http://www.kinzelman.com/tech/encryption-for-idiots.html ___ 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
How-to guide for email encryption
I created a file to help a newbie get email encryption going. It's what I wish I could have found when I was stumbling through the process myself, and with the help of an expert in this newsgroup (many thanks to you, you know who you are :-), I've created a document for others. Feel free to pass the link around and to comment and suggest enhancements. http://www.kinzelman.com/tech/encryption-for-idiots.html ___ 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/18/2008 03:54 AM, Eddy Nigg: Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of "information gathering" in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. I forgot to mention, that in case inclusion is relevant we should gather additional information about the auditor and independent confirmation of the audit report. -- 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/14/2008 11:12 PM, Frank Hecker: >...in the short term I'm going to try to restart CA public discussions on a regular schedule. Nice to see you back here! First, the general issue of auditing subordinate CAs was something we didn't think through much when we did our Mozilla CA policy: We were thinking of a fairly simple model where a CA organization operated both its root CA(s) and also any subordinate CAs under those roots, with a CPS and associated audit that covered the both root and subordinates all. In actual practice things are more complicated, and our policy didn't really capture that complication. I'm glad that this issue is recognized as such! My personal opinion is that it doesn't make sense to try to address this complication by mandating traditional WebTrust-style audits of any and all subordinates under a root. I think this approach is impractical, and I don't think it's necessary. I'd rather look at the overall manner in which CAs exercise controls over subordinates, legally, technically, and otherwise, as well as the general nature of the subordinates and how they function in practice. Even though your statement would on general issues make sense, we must also recognize that it would be very difficult to implement. First of all it's a matter of policy and every time the policy didn't address a specific issue in the past we were in a Grey area. The "problematic practices" were implemented as a result of it. I believe that the policy (and/or other relevant policy guiding statements) should be clear in respect what Mozilla requires from the CAs. This is important for planning and preparing for the CAs themselves, it's important for us in order to make the right judgment. I think that a case-by-case approach is at least unfair and hardly sustainable in the long term. Incidentally those CAs which would be most likely acceptable by the terms you outlined above, are usually the ones which either audit their whole infrastructure or are not affected by the problematic practices of sub-ordinate CAs in first place. But obviously it's difficult to draw a clear line... There are various risks Mozilla needs to be prepared to take in case no clear policy is defined, mainly the inclusion-by-proxy of CAs (it rather would not have included) and questionable practices of sub-ordinate CAs. Additionally I believe that Mozilla shouldn't take the risk of including CAs (sub-ordinate or not) *without* having their physical and logical infrastructure confirmed and audited. Specially problematic are those which are independent entities in relation to the root CA and operate their own infrastructure (inclusion by proxy). It makes no sense whatsoever to require auditing of a root, if the issuing CA isn't audited at all. Recent examples have shown that it's no guaranty for adherence to the Mozilla CA policy - despite the fact that the very same (cross-signed or sub-ordinate) CAs were actually audited independently!!! (I refrain from getting into the auditing aspects, but it makes a great deal and difference for all parties involved. Otherwise Mozilla and the other browsers wouldn't made it a requirement from the beginning.) I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not. Can you define those cases? What are the requirements and where doesn't and where does it make sense? How to draw the line? You must be specific in order for us to understand the differences! For purposes of this particular evaluation, my goal is for us to gain a shared understanding of what WISeKey actually does, including getting answers to any remaining questions, and then I'll make a judgement call as to whether what WISeKey is doing meets the general intent of our policy. In this particular case I think that the practice in question doesn't meet the requirements of the Mozilla CA policy. This includes in particular section 6 and 7 of the Mozilla CA Policy. WISeKey has been through an initial comment period a while back, during which we got nvolved in a lengthy discussion about WISeKey's Blackbox product (a "CA in a box" product intended for enterprise deployment) and whether and how auditing was done for WISeKey's subordinate CAs associated with that product. WISeKey supplied more information about their arrangements, which you can find in the bug. Frank, I greatly missed the thorough and systematic work of Kathleen in this bug and it's a pity she didn't perform another round of "information gathering" in case some new evidence was provided. Anyhow, I couldn't find anything new in the bug since the last time. I'm not sure what is supposed to have changed. Since I can't find anything new, I assume that nothing has changed and therefore the condition for inclusion didn't change at all. If we consider that all recent inclusion requests were specifically tested for such practices - most notably CAs like Como
Re: subroots (was WISeKey)
On 11/15/2008 06:29 PM, Ian G: I agree it is an issue that we should try and clarify, if not nail down. Sounds good! One way to short-circuit this is to simply state that the root CA is responsible for any/all subroots. This is the situation we had until recently, with CAs under their own control. Of course the CA is "responsible" for all its sub roots... So this would imply that the root CA's policies and audit drill down through the subroots, and they apply. Then, it would be up to the root auditor to decide whether a subroot needed a separate audit or not. Except that some CA policies many times don't even cover the aspects of the sub ordinate CAs. Such "root" CAs are simply audited as their CP/CPS defines. An auditor is not required to audit something not claimed in their policies. Auditors generally confirm the claims made in the CP/CPS, not those that aren't made. One problem with this is that it might also not be realistic. Consider two CAs, one of which does "style A" and another does "style B". In the doco and audit for the root CA, there will be a need somehow to capture that distinction. The natural direction here will end up that the root's policies will tend to say "see the subroot's policies for more detail." If that policy was part of the audit, that would already provide good indications. So Mozilla's review of this will be looking at a blank spot. E.g., future subroots. I see this contrast all frequently. We accept the base situation, then the CA goes and issues another subroot. Suddenly a whole new class of activity has occurred, and there is no check done on this until the next audit, and none at all by Mozilla. Right. It was suggested to require a yearly audit or by other frequency. Either way we look at it, I feel that the more controls are put in place, the more we end up putting in "paper fixes" and the more we complicate things for a gain that we don't fully understand. I don't perceive it as such at all. What do we not understand? There is a very competent team at work (Kathleen, Gerv, Frank) and a few of us here. I think the issues are fully understood. Alternatively, we just set the responsibility, and pass it to the root CA. That's what we had previously. Some easy-to-find flaws already have been detected (DigiNotar, Staat der Nederlanden). Those were just the ones we came across by chance, I don't even want to know about everything we don't know. In this we could typically include the disclaimers of liability, and how we would deal with the disputes, e.g., over the activities of the CA's wilder subroots, and at an extreme level, any root revocation at Mozilla's discretion. One of the problems is of course that no follow ups exist currently as you correctly stated above. So far nobody has ever dedicated time to review CAs not up for inclusion. -- 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: MITM in the wild
On 11/15/2008 05:18 PM, Ian G: Eddy Nigg wrote: On 11/12/2008 05:21 PM, Ian G: Not sure why, but your posting arrived just only now... What is clear is that the name is not really the essence of the process, it is just one part. So if we are claiming the full essence of getting people to court, we need to do other things; We'd rather prefer to remain out of court, but that's the ultimate option. The fact that identification details are listed in a certificate usually is a prevention measure itself. if we are just doing the Name, we should avoid talking about the courts purpose unless we can point to the other things as well, and show how it fits in. But not only the name is validated usually, but address, locality as well. The street address is many times not listed for non-EV certs, but it would by court order possible to be disclosed. You can, sure. But would you? Would you dare to masquerade as another person, and do some harm? It's not about me, but anybody who dares. Many do as your own junk folder can provide evidence of. It's the easiest thing in order to perform fraud. Let's say you do that, and then the summons arrives to your email address. You see the summons. What are you going to do? LOL! That's really naive thinking! Do you really believe that somebody disguising his identity will bluntly use his own real IP address. :-) Do you dare defy the court and not present yourself? If you do that, then you are toast. If they (a claimant and a real bill gates) come looking for you and find you, then not only have you committed a species of deception, you've tried to ignore the courts. Not only is your case compromised, but you've probably committed something against the court. The problem is, nobody will ever know that it was me... Instead, because you are a wiser person than that, you will simply appear before the court, and say, "It is I, using that nym, but my real name is Bob Smith." And the court will proceed to hear the case. At least in english common law, it is OK to use any name you like, as long as it isn't for fraudulent purposes. Or if there aren't such intentions in first place use a validated digital certificate. These days an unsigned mail should be always consumed with a grain of salt... If a claim is made by CAs that the Name is needed to pursue someone in the courts, this is more or less deceptive. Ha? Can you explain that? Here some example details strait from a certificate: E = [EMAIL PROTECTED] CN = Eddy Nigg L = Eilat ST = South C = IL What's deceptive here? Additionally the CA has more information about the subject such as the address and phone number. If we accept that (and we are in a security market, regulated by audits and/or vendors) then we should stop making that claim. There is no claim to stop! The quality of the verification performed may vary, but as a general rule, a verified certificate is sufficient to reach the person in question (by court order or else). Of course a crook may change address, but courts and law enforcement officials have their tools to locate somebody sooner or later. Provided that the persona in question is identified correctly. OK. So the principle is that everyone may make their own risk assessments, whether private or corporate. We may freely decide to allocate our resources and make our decisions. As I said, resources which are truly under my control, I may require a verified identity too! I didn't meant a browser here, but rather other resources, like a web site or mail server. It would also mean that a vendor was free to experiment and choose different security models c.f. Gerv's much lamented yellow bar and Jonathon's 4-click process. Isn't that what happened really? Not seeing your point. -- 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
subroots (was WISeKey)
Frank Hecker wrote: We've had some lengthy discussions about the issue of auditing subordinate CAs. I'm not going to rehash all those discussions, I'll just summarize my current thinking: First, the general issue of auditing subordinate CAs was something we didn't think through much when we did our Mozilla CA policy: We were thinking of a fairly simple model where a CA organization operated both its root CA(s) and also any subordinate CAs under those roots, with a CPS and associated audit that covered the both root and subordinates all. In actual practice things are more complicated, and our policy didn't really capture that complication. Yes, I agree. IMHO, the policy has served remarkably well, and of course issues will arise with more experience. My personal opinion is that it doesn't make sense to try to address this complication by mandating traditional WebTrust-style audits of any and all subordinates under a root. I think this approach is impractical, and I don't think it's necessary. I'd rather look at the overall manner in which CAs exercise controls over subordinates, legally, technically, and otherwise, as well as the general nature of the subordinates and how they function in practice. I think in some cases it might make sense to require audits for all subordinates, and in some cases it might not. Some musing on this. I agree it is an issue that we should try and clarify, if not nail down. One way to short-circuit this is to simply state that the root CA is responsible for any/all subroots. So this would imply that the root CA's policies and audit drill down through the subroots, and they apply. Then, it would be up to the root auditor to decide whether a subroot needed a separate audit or not. One problem with this is that it might also not be realistic. Consider two CAs, one of which does "style A" and another does "style B". In the doco and audit for the root CA, there will be a need somehow to capture that distinction. The natural direction here will end up that the root's policies will tend to say "see the subroot's policies for more detail." So Mozilla's review of this will be looking at a blank spot. E.g., future subroots. I see this contrast all frequently. We accept the base situation, then the CA goes and issues another subroot. Suddenly a whole new class of activity has occurred, and there is no check done on this until the next audit, and none at all by Mozilla. One way to deal with that is to add a criteria that says "audit should list the allowed subroots" or somesuch. So new subroots would have to wait until the next audit. But this might slow down the process, add complication, push the audit into too much management, and be also somewhat arbitrary; CAs can be inventive and find ways around it, and audits might be sympathetic to these ideas. Mozilla only does one review, so in time the topic will drift. Either way we look at it, I feel that the more controls are put in place, the more we end up putting in "paper fixes" and the more we complicate things for a gain that we don't fully understand. Alternatively, we just set the responsibility, and pass it to the root CA. This does somewhat put the finger on the relationship between the CA and Mozilla. Currently, this is an informal agreement based on the policy, bug filing, and other communications. What might be better is a single document (or mod to the policy) that specified what the complete agreement was (listing the others). In this we could typically include the disclaimers of liability, and how we would deal with the disputes, e.g., over the activities of the CA's wilder subroots, and at an extreme level, any root revocation at Mozilla's discretion. iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Eddy Nigg wrote: On 11/12/2008 05:21 PM, Ian G: No it's not. You just need the person, not their identity. LOL, you are funny...and how exactly do you get the person if you don't know who it is that you need? This is what the (verified real) identity details in certificates are here for... Wel... the system of courts isn't quite "funny" although there are some non-understandable aspects, and lots of myths about it. People often believe crazy things about how the courts act, like they are fair and just and they will protect you against bad people. In order to get someone to court, it generally depends on the jurisdiction you are in. In the english common law tradition, papers have to be served to the person. So you have to find the person, some way or other. (Having the name is useful, but what is more useful is knowing how to find the person, such as the physical address.) In other jurisdictions, it works other ways. In modern day cases, judges will often accept you emailing the papers to the person, if the email address is the only one you know, and this will work as long as your case is good. In civil code jurisdictions (Europe) the process is different, and I don't really understand it. (Bear in mind normal IANAL caveats :) What is clear is that the name is not really the essence of the process, it is just one part. So if we are claiming the full essence of getting people to court, we need to do other things; if we are just doing the Name, we should avoid talking about the courts purpose unless we can point to the other things as well, and show how it fits in. If you need to get someone in court, they either come willingly, in which case nothing is needed, or you need to find the person. You still need to know who it is that you want to get to court... In US court, you can file against John Doe, and the court can then help you find the body (by means of a real name or by other means). In other places they insist on at least a name of some form, although it might not be the real name. "Known aliases" and "a.k.a." for example. courts will these days accept an email address if the circumstances are appropriate (e.g., that's how he closest you got when doing business). Most likely not. I can be [EMAIL PROTECTED] any time I want. You can, sure. But would you? Would you dare to masquerade as another person, and do some harm? Let's say you do that, and then the summons arrives to your email address. You see the summons. What are you going to do? Do you dare defy the court and not present yourself? If you do that, then you are toast. If they (a claimant and a real bill gates) come looking for you and find you, then not only have you committed a species of deception, you've tried to ignore the courts. Not only is your case compromised, but you've probably committed something against the court. You will likely lose that case. "Default judgment" or worse. Instead, because you are a wiser person than that, you will simply appear before the court, and say, "It is I, using that nym, but my real name is Bob Smith." And the court will proceed to hear the case. At least in english common law, it is OK to use any name you like, as long as it isn't for fraudulent purposes. Because if you claim that it is needed to resolve disputes, then this may be deceptive. (At the least, you should figure out why it is needed and use that reason.) What's new here? If a claim is made by CAs that the Name is needed to pursue someone in the courts, this is more or less deceptive. It is like a claim that anti-wrinkle cream will make you younger. To the extent that anti-wrinkle cream makes you feel younger, that's kinda-ok because fashion is like that, we don't as a society apply high standards in that market. But it is not acceptable to build any regulated or mandated product on such an unfounded claim, and it is not acceptable in a security market. If we accept that (and we are in a security market, regulated by audits and/or vendors) then we should stop making that claim. Unfortunately, this then creates a big hole in the process: what was the Name there for? If it hasn't got a serious purpose, then it is a fashion accessory. If it is a fashion accessory then we don't need stringent controls. Fashion is choice, not regulation. Or, if it has got a serious purpose, what is that? Then, we can look at how to regulate that. (One thing should be clear: if a Name is in the cert, the CA is making a claim about that name. If it issues you a cert with "Bill Gates", we might validly ask what then is the claim?) According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. OK, I buy that. Would you sign to that as a principle? I think so, yes.
Re: NSS DB migration problem
Hans Petter Jansson wrote: This works for some databases, but not others. It doesn't seem to matter which application created the database (I've tried with databases from Firefox and Evolution) - e.g. one user's database may fail while another user's database may migrate properly. When it fails, it's always on the first PK11_Authenticate () call (step 3). The code above produces the following output: *** Auth call failed: 4294959104. That is, 0xe000. If I set up an auth callback, it never gets called. Do you have any suggestions as to what I'm doing wrong here? Do these databases have passwords set on them? Also, does certutil --merge on these databases? bob 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: how to decrypt with pubkey without pkcs1 padding things
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? bob 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
Import .cer into my .keystore
Hi I am having 2 different keystores. One is having a cert for one particular client which the other is not having. My plan is to export the car from the first available one and import the same into the other which is not having that. For this i am trying the following steps. 1. Export the .cer from the Keystore. 2. Import the .cer to other key store. Export is working fine and it is generating the .cer file. But the problem is with import. I am not able to import the generated one in to any other keystore. Note: Both the the keystores are of type PKCS12. Can any one explain where I am taking the wrong step? Thanks Kalukuri ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
