Re: NSS DB migration problem
On Sat, 2008-11-15 at 19:06 -0800, Nelson B Bolyard wrote: > Hans Petter Jansson wrote, On 2008-11-15 17:57: > > It's on separate workstations, but in some cases one database migrates > > successfully while another fails on the same system. > Is is possible that more than one version of the NSS shared libraries is > installed, and that the two users have different LD_LIBRARY_PATHs, so > that the two users are getting different versions of the NSS when they > attempt this? It's highly unlikely. > > 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 :) -- Hans Petter Jansson <[EMAIL PROTECTED]> ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: subroots (was WISeKey)
On 11/19/2008 03:56 AM, Ian G: Yes, and at a technical level I don't see an issue. At a legal/liabilities level I see an open question: who is taking on the liability, how is it shared, etc. ...and I might add, how are the basic requirements of the Mozilla CA Policy governed... I also think it helps a lot to define the target of the security model. Who are we trying to protect? I say the end-user (and have said so in recent documents) rather than say Mozo or the CA or whoever else we might encounter in the path. 100%! Certification is about the relying party, nothing else. I'm not actually sure a "formal legal agreement" is needed. I suggested and supported the call for a formal agreement between the CAs and Mozilla a while ago. It would strengthen the relationship and commitment to the Mozilla CA Policy. Without it, governing CAs is rather difficult. From which I would say that a good model is to simply state the policy as a "posted notice" with a clause that states "by submitting your root to the bugzilla for consideration, you agree to the terms and conditions of this policy." Adding that sort of clause to the policy should be a lot easier than trying to craft some sort of "mutual agreement." This could be another way doing the same thing. Obviously signing a real paper is a stronger act than simply agreeing to a policy statement. -- 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: How to use SECMOD_LoadUserModule and SECMOD_UnloadUserModule
Wan-Teh Chang wrote:
The SECMOD_LoadUserModule and SECMOD_UnloadUserModule functions
were added in https://bugzilla.mozilla.org/show_bug.cgi?id=132461, but no
NSS utilities or test programs use these functions, so the only sample code
for these functions that I can find is PSM.
PSM uses these functions as follows:
In nsNSSComponent::InstallLoadableRoots:
812 RootsModule =
813 SECMOD_LoadUserModule(const_cast(pkcs11moduleSpec.get()),
814 nsnull, // no parent
815 PR_FALSE); // do not recurse
816
817 if (RootsModule) {
818 PRBool found = (RootsModule->loaded);
819
820 SECMOD_DestroyModule(RootsModule);
821 RootsModule = nsnull;
822
823 if (found) {
824 break;
825 }
826 }
In nsNSSComponent::UnloadLoadableRoots:
839 SECMODModule *RootsModule = SECMOD_FindModule(modNameUTF8.get());
840
841 if (RootsModule) {
842 SECMOD_UnloadUserModule(RootsModule);
843 SECMOD_DestroyModule(RootsModule);
844 }
SECMOD_DestroyModule is not documented in
https://developer.mozilla.org/en/NSS_PKCS11_Functions, so it's not clear
what the side effects of SECMOD_DestroyModule are and why PSM calls
SECMOD_DestroyModule after both the SECMOD_LoadUserModule and
SECMOD_UnloadUserModule calls.
SECMOD_DestroyModule destroys the reference to the Module. (Lots of
functions return references to the module).
The following functions return module reference that must be destroyed:
SECMOD_FindModule
SECMOD_FindModuleByID
SECMOD_ReferenceModule
SECMOD_CreateModule (I don't know why this one was exported... It
probably shouldn't have been).
SECMOD_LoadModule
SECMOD_LoadUserModule
The follow returns a module, but does not return a new reference:
SECMOD_GetInternalModule
The following functions also link a module into various internal lists:
Default trust
domain Module ListsPersistant database
(secmod.db/pkcs11.txt)
SECMOD_AddNewModule
y
y y
SECMOD_AddNewModuleEx
y
y y
SECMOD_LoadUserModule
y
y n
SECMOD_LoadModule
n
y n
Module lists hold a reference to the module. The default trust domain
holds a reference to each slot in the module (but not the module itself).
The following functions remove a module into various internal lists:
Default trust
domain Module ListsPersistant database
(secmod.db/pkcs11.txt)
SECMOD_DeleteModuleExy (if there)
y (if there) if (permdb
== TRUE)
SECMOD_UnloadUserModule y (if there)
y (if there)n
Neither SECMOD_DeleteModuleEx nor SECOD_UnloadUserModule free's the
caller's reference to the module.
(Looking at the code it looks like SECOD_UnloadUserModule is doing more
work than it needs. It uses SECMOD_DeleteModuleEx, but also calls
STAN_RemoveModuleFromDefaultTrustDomain(), which may be redundant).
bob
Is it true that SECMOD_DestroyModule merely does reference counting,
and won't cause the module to be unloaded?
Does SECMOD_UnloadUserModule not destroy the module structure, contrary
to what this source code comment says?
http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11pars.c#406
406 /*
407 * remove the PKCS#11 module from the default NSS trust domain, call
408 * C_Finalize, and destroy the module structure
409 */
410 SECStatus SECMOD_UnloadUserModule(SECMODModule *mod)
The comment should be updated. It removes the module structure from the
system and deletes that reference. If the user is still holding a
reference, the module will not be deleted until that reference is removed.
Thank you!
Wan-Teh
___
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
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
Web Signing. Re: Slamming S/MIME. Re: How-to guide for email encryption
Collective posting to save list-space. Aka "green" posting :-) Eddy Nigg wrote: >> i.e. the concept of "Web Signing"? >What is this supposed to be? Perhaps I missed it? Ian G wrote: >What is "Web Signing?" >And, what are the requirements? As I wrote in my previous "Slamming S/MIME" posting, maybe some 10M people are already using this, albeit with entirely proprietary software. The difference with this concept compared to S/MIME is that it is based on a user and service on the web. What does that match? Well, On-line banking, C2G services, in-house workflow systems, purchasing system, and thousands of variants of cloud computing services. Since it is based on the web, encryption comes at no cost and [almost] no thrills. Regarding Ian's very valid question what the requirements this is [sort of] the fun part: Since nobody has been able to specify what they and why they want it, I have essentially defined all this by myself! Or to be more correct, I have designed a scheme and then asked a few people if it would work for them. Ian G wrote: >And, why do I feel that this will be something we'll return to in 5 years ;) A bunch of people will certainly do that while putting the self-reflecting question: Why did we pass on this one, allowing a single moron defining the stuff that everybody uses? As we say in Sweden: Don't take it as a threat - Take it as a promise :-) :-) There are some pathetic actions within ETSI and BSI to come up with a "challenger" but it will surely be an over-specified (German influences...) monstrosity that it will die under its own weight. Sincerely Anders Rundgren ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Slamming S/MIME. Re: How-to guide for email encryption
Anders Rundgren wrote: Guys, Let's return to this topic in 5 years or so and see if S/MIME actually has gotten any further with respect to uptake. You and me obviously have the opposite position on this one. Sort of "Yes we can" versus "No, you can't" to paraphrase a recent moment in world history :-) They say that optimists have more fun than pessimists, so you are at least on track in this respect :-) I see the question as really one for Mozilla Communications team. How much resource are they going to put into this area, and to what extent are they going to deal with the architectural weaknesses? If "lots", then the optimists will smile again, if nix then the pessimists will enjoy their misery. I see it this way: back in the early 1990s, we knew something. Now we know a whole lot more. Some things that were built in those days sorta worked, by fate or luck or design, and some things were doomed. There's not a lot of point in getting hung up about it. 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"? Do you have any suggestions on how to proceed to make it a built-in feature of Firefox? Although it would be nice just contributing some code, I believe that a useful solution must be "architected" a bit, and I'm not a Mozilla architect. What is "Web Signing?" And, what are the requirements? And, why do I feel that this will be something we'll return to in 5 years ;) iang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Slamming S/MIME. Re: How-to guide for email encryption
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? -- 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: Slamming S/MIME. Re: How-to guide for email encryption
Guys, Let's return to this topic in 5 years or so and see if S/MIME actually has gotten any further with respect to uptake. You and me obviously have the opposite position on this one. Sort of "Yes we can" versus "No, you can't" to paraphrase a recent moment in world history :-) They say that optimists have more fun than pessimists, so you are at least on track in this respect :-) 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"? Do you have any suggestions on how to proceed to make it a built-in feature of Firefox? Although it would be nice just contributing some code, I believe that a useful solution must be "architected" a bit, and I'm not a Mozilla architect. Best regards Anders Rundgren ___ 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/19/2008 03:29 PM, Michael Ströder: I wonder how you want to limit the domains via name constraint extension in current business practice. I have a customer who has ~2 registered domains. They bought another big company with ~3 registered domains. They usually register all variants of product names under all top-level domains so the number is growing quite fast. For each domain there MAY be SSL certs issued by an own sub CA. In this environment the naming constraints are just defined by contract with the root CA owner not by cert extension. Well, this is what the CPS of Wisekey apparently says, not my invention. It wouldn't be our problem how this would be implemented in the case above. I stated what would be acceptable in my opinion - with naming constraints being clearly conditional. Basically your customer wouldn't fall under this category and would have to be audited as any other CA, certainly with 20K and more domains under their control. Make sense in my opinion (because of the higher risk and wider audience of the relying parties). -- 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)
Eddy Nigg wrote: The Wisekey case 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); I wonder how you want to limit the domains via name constraint extension in current business practice. I have a customer who has ~2 registered domains. They bought another big company with ~3 registered domains. They usually register all variants of product names under all top-level domains so the number is growing quite fast. For each domain there MAY be SSL certs issued by an own sub CA. In this environment the naming constraints are just defined by contract with the root CA owner not by cert extension. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
SV: Slamming S/MIME. Re: How-to guide for email encryption
Graham Leggett wrote: > What is "content checking" and what does it have to do with security? FYI In Denmark a nationwide PKI has been deployed in the last couple of years. Very soon after the start we realized that content scanning and S/MIME was clashing in a number of organisations. We (the CA in Danmark) solved this issue together with a number of suppliers of secure e-mail solutions. The concept was denoted "split certificates" because the functionality of signing and decryption is split between a central and a local part. The concept is described in https://split.certifikat.dk/Split_concept_desc_v1-0.pdf And for people with more technical interest https://split.certifikat.dk/Split_technical_desc_v1-0.pdf The document is written to people with some knowledge to the Danish infrastructure, but should be readable to other. Note: The solution primary address organisations and not citizens' usage. Note: The TDC PKI activities have recently been sold to DanID, so the documents is subject change in layout. Regards Peter Lind Damkjaer ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox' password manager with sqlite based NSS
Wolfgang Rosenauer wrote: > Wolfgang Rosenauer schrieb: > >>> Are you trying to use NSS_InitWithMerge to create a new cert9.DB >>> where none existed before? >> Yes. NSS_InitWithMerge is used regardless of an existing cert9.db (and >> even cert8.db). The conversion function uses pretty much what is on >> https://wiki.mozilla.org/NSS_Shared_DB#Type_A mentioned as "simple >> update". Only if NSS_InitWithMerge fails it does NSS_Initialize instead >> to create the new db but that didn't happen. >> >>> I'm pretty sure that that function has not been tested for that purpose. >>> Perhaps it needs to detect the case where the "target" DB does not >>> already exist and handle it differently. >> As far as I can see https://wiki.mozilla.org/NSS_Shared_DB is unclear >> about the fact if it can be used to create a db from scratch. > > I can confirm that NSS_InitWithMerge doesn't create a working database > here at least if none existed before. So it should either fail or handle > that case in future versions. I'll try some more things. Wolfgang, Thank you for your continued efforts in this area. Please file a bug in bugzilla about this finding. A small test program would be VERY helpful, but not absolutely essential. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox' password manager with sqlite based NSS
Wolfgang Rosenauer schrieb: >> Are you trying to use NSS_InitWithMerge to create a new cert9.DB >> where none existed before? > > Yes. NSS_InitWithMerge is used regardless of an existing cert9.db (and > even cert8.db). The conversion function uses pretty much what is on > https://wiki.mozilla.org/NSS_Shared_DB#Type_A mentioned as "simple > update". Only if NSS_InitWithMerge fails it does NSS_Initialize instead > to create the new db but that didn't happen. > >> I'm pretty sure that that function has not been tested for that purpose. >> Perhaps it needs to detect the case where the "target" DB does not >> already exist and handle it differently. > > As far as I can see https://wiki.mozilla.org/NSS_Shared_DB is unclear > about the fact if it can be used to create a db from scratch. I can confirm that NSS_InitWithMerge doesn't create a working database here at least if none existed before. So it should either fail or handle that case in future versions. I'll try some more things. Wolfgang ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Paul Kinzelman wrote: Wow, I guess I really opened a can of worms. Interesting discussion, but like somebody said, it's really off the original topic I posted. You should have a look at the ietf-pkix mailing list archive to a get a feeling about more cans of worms. ;-) I'm just glad to contribute something to others that are trying to wack themselves a way through the jungle of getting secure email off the ground. And that's much appreciated! Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Julien R Pierre - Sun Microsystems wrote: Michael, Michael Ströder wrote: Anders Rundgren wrote: IM[NS]HO, S/MIME encryption using PKI is one of the biggest security farces ever. I don't see why. 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). This is nonsense. Passing a shared secret to somebody else would be impractical. I agree with you if you are talking about sharing that secret instantly with any other random person line. Yes, that's what I meant. However, sharing secrets is done routinely with a limited number of entities in a variety of ways, eg. you go to your bank to set your ATM card pin, or (gasp) over the phone. My insurance company sends a temporary password through postal (smail) mail the first time you sign up for email access. I think you can also sign up in person at the hospital. Yes, it's also often done during cert enrollment. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How-to guide for email encryption
Julien R Pierre - Sun Microsystems wrote: My insurance company chose to deploy webmail with an HTTPS interface with a shared-secret login (password) for secure messages between patient and doctors. As a result, I cannot (easily) archive the messages I receive and send locally. I have to login to a web site every time to look at them. And that web site sets the archiving policy. Especially the lack of control over the archiving policy can really bite you. However, it's obvious that the system they deployed is much simpler to use than S/MIME. Still, my dietitian finds it too complicated, and can only be contacted through regular insecure email to this day. And that's exactly the point: Your dietitian don't have to use encrypted e-mail. If it would be a MUST (by law or similar regulations) he would. That's a non-technical issue and cannot be solved by yet another technical approach which looks more "easy" to some people. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
