Re: Invalid certificate alert
John Gardiner Myers wrote: This has been filed as bug 235585. Currently, PSM is determining what to fingerprint itself, it isn't calling into NSS. I'd appreciate if you could provide details of what was changed and when in the bug, so I can decide whether to fix it or not. Several points about this proposal. 1. Fingerprints are only used for people to verify that they have the same cert, e.g. over the phone, and this is needed only when importing new roots, or otherwise previously untrusted certs. To that end, it is vital that NSS, PSM, OpenSSL and others compute fingerprints in the same way, as they now do. The agreed algorithm is to compute the hash over the entire cert, stem to stern. If PSM changes it unilaterally, it will no longer be possible for OpenSSL users to compare results with mozilla users. 2. fingerprints are irrelevant to Henrik's issue. NSS doesn't use fingerprints internally when comparing two certs to see if they are or are not equal, so the fingerprint algoirthm is completely irrelevant to that issue. 3. When comparing two certs to see if they are identical, it is necessary to compare (a) the signed data, and (b) the signature itself. 4. For two signatures to be equal, they must have the same length (in bits), and all the bits within that specified length must be the same. If the two signatures are of equal length, and both have an equal number of unused bits, and the unused bits differ, then I could be persuaded that those signaures are nonetheless identical. BUT THAT IS NOT THE SITUATION HERE. In this case, it is not the actual unused bits that differ, but rather it is the NUMBER OF UNUSED BITS that differ. One cert claims to have a 2048 bit signaure (no unused bits). The other claims to have a 2047 bit signature (1 unused bit). Hence the two signatures are not of equal lengths, and therefore CANNOT be identical. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Trusted CAs must offer primary support to their customers and relying parties
Nelson Bolyard wrote: It simply MUST NOT become the case that everyone who has a problem with a cert from a trusted CA receives their customer support from mozilla. CAs cannot rely on bugzilla.mozilla.org as their bug tracking system. But it will happen if NSS is the only application around enforcing some rules. Maybe the best solution would be an on-line page that can test certs, and tell with a lot of details, references to the norms, what is wrong in them. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Julien Pierre wrote: Thanks for tracking the problem down with the certificate ! Well, I try to not only be the guy who constantly bugs you about the /right/ way to validate a CRL ;-) ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed CA certificate metapolicy - 7. threat models
Julien Pierre wrote: Actually having separate builds for localized versions is a can of worms in itself. Are the localized builds built from separate branches ? I was under the impression that they simply had additional language modules. The usual practice, I believe, is to swap out the language XPI and region XPI, and perhaps change the home page. Some places (like the Japanese) also apply patches for bugs which are really irritating in their locale. Gerv ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Jean-Marc Desperrier wrote: I didn't require that :-) I believe this also means you use the same alg as Microsoft CAPI which makes things simpler for everybody. And the specification for that algorithm would be where ? The signed part of them should. The unsigned part is not required to. Can you give any pointer to specs that document this ? In fact, openssl used to produce all certs with some BER elements in the unsigned part in the earlier versions (0.9.4). And as many CA don't issue truly DER encoded certificate, every toolkit just has no choice but to support it. Actually, NSS has not supported any BER encoding in certs since version 3.6, about a year and a half ago, since the QuickDER decoder was introduced and used in the cert dedcoding, as opposed to the more versatile but much slower BER/DER decoder. This padding issue is the first one I hear about that points to BER encoding in certs. So, perhaps CAs really do issuer DER certificates ? Or users of CAs that don't aren't using any NSS-based products such as Mozilla. Therefore, opposite to what I thought before watching in exact details, the version that has one unused bit set is the correct DER encoding version, and the one that does not set one unused bit, but instead includes it with a value of zero, is BER encoding and not DER encoding. The decoded value of the signature is exactly the same in the two case, so it's normal that signature verification does not fail. No, they are two different cases. The example you cite in the key usage is not a plain BIT STRING, but rather a named bit list, and the DER encoding for that dictates the shortest possible encoding, which in this case means truncating the upper byte if all its bits are 0, and removing the upper bit in the lower byte, if it is zero. Signatures are encoded as plain BIT STRING, not a named bit lists. The DER encoding rules for it specify that upper bits should not be removed even if they are zero. Imagine a 2048 bits RSA signature that just happened to have all 1024 upper bits set to zero. If encoded as name bit string like key usage, it would be indistinguishable from a 1024 bit signature. The DER encoding for BIT STRING must only remove the bits that are not part of the string, not all non-significant zeroes. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Trust certificates in HW-Tokens
Hi all, I am aware of the problems of storing trust in Hardware-Tokens. I'd really like to see Bug#154255 fixed. I tried to work around this fact by *not* storing the CA fo my email-Cert on the token. The CA is in the built-in module and it is marked as beeing trusted for identifying web-sites, emails and authors. Nevertheless, Thunderbird keeps complaining Unable to sign message. Please check, that the certificates specified in Mail Newsgroups Account are valid and trusted. Whats wrong? If I view my email-cert, it is being shown with the validation-chain, so the CA-Cert is found. If I view my CA, it is marked as trusted. I am using the PKCS#11-driver from OpenSC with a Schlumberger Cryptoflex 32K. Card contens are as follows: openscp15dump Using libopensc version 0.7.0. Card detected in reader 'Schlumberger e-gate 0' Connecting... connected. ATR = 3B:95:18:40:FF:62:01:02:01:04 Looking for a PKCS#15 compatible Smart Card... found. PKCS#15 Card [OpenSC Card]: Version: 1 Serial number : Manufacturer ID: OpenSC Project Flags : EID compliant Enumerating PIN codes... 1 found. PIN (no label) Com. Flags : 0x3 Auth ID : 01 Flags : [0x32], local, initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char: 0x00 Reference : 1 Encoding: ASCII-numeric Path: 3F0050154B01 Enumerating Private keys... 1 found. Private RSA key [Private Key] Com. Flags : 0xD Com. Auth ID: 01 Usage : [0x32E], decrypt, sign, signRecover, unwrap, derive, nonRepudiation Access Flags: [0x0] ModLength : 2048 Key ref : 0 Native : yes Path: 3F0050154B010012 ID : 45 Enumerating Public keys... none found. Enumerating X.509 certificates... 1 found. X.509 Certificate [/C=DE/CN=Andreas Marx/emailAddress=Andreas DOT Marx AT neox DOT de] Com. Flags : 0x2 Authority : no Path: 3F0050155501 ID : 45 Enumerating data objects... none found. opensc [X.509 actually contains correct DN with email-Adress as being used in email-Account] Any help would be appreciated, Andreas ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed CA certificate metapolicy - 7. threat models
Frank Hecker has mentioned in his draft of a metapolicy that a threat model should be used. AFAIK, there is only a fairly poor attempt at a threat model for browser security, a great lack in the original design. Here is my attempt at a threat model: http://iang.org/ssl/browser_threat_model.html Comments welcome. One thing - I've not found any doco on how a threat model is written out, so I'm in the dark a bit. But, ignorance is no excuse for not trying... iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Trusted CAs must offer primary support to their customers and relying parties
Jean-Marc Desperrier wrote: Nelson Bolyard wrote: It simply MUST NOT become the case that everyone who has a problem with a cert from a trusted CA receives their customer support from mozilla. CAs cannot rely on bugzilla.mozilla.org as their bug tracking system. But it will happen if NSS is the only application around enforcing some rules. Well, it simply hasn't been a problem with any but 1 or 2 of the professionally operated CAs now in the trust list. It has primarily been a problem with little homebrew CAs. Maybe the best solution would be an on-line page that can test certs, and tell with a lot of details, references to the norms, what is wrong in them. That would be a nice tool, but mozilla is certainly not obliged to produce it, nor likely to IMO. Considering how few people ever contribute to mozilla's security, it would seem even more unlikely that they'd contribute to such a project. To carry my proposal one step farther, once there are some good (meaning well run, trouble free) low cost CAs in the trusted list, I think mozilla's policy should simply refuse to accept bug reports from people who are still out there trying to be their own CAs, sans clue. The policy would say that bug reports are accepted regarding certs from the trusted CAs, only, and not from non-trusted CAs. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
JSS : Error with Import .p12 File with PFX.main and other... :(
Hi all I'm trying to import a .p12 file into Mozilla/Netscape Certificate Manager... I have try some things to know and understand JSS ( need more explaining docs... )... For my Job, i need to import a .p12 file into the manager. I have try with PFX.main but i have an error : Decoded PFX Version: 3 AuthSafes has 2 SafeContents AuthSafes verifies correctly. java.security.InvalidAlgorithmParameterException: RC2/CBC/NoPadding cannot use a null parameter at org.mozilla.jss.pkcs11.PK11Cipher.checkParams(PK11Cipher.java:250) at org.mozilla.jss.pkcs11.PK11Cipher.initDecrypt(PK11Cipher.java:136) at org.mozilla.jss.pkcs7.EncryptedContentInfo.decrypt(EncryptedContentInfo.java:290) at org.mozilla.jss.pkcs12.AuthenticatedSafes.getSafeContentsAt(AuthenticatedSafes.java:179) at org.mozilla.jss.pkcs12.PFX.main(PFX.java:374) When I try to make my progs to read and import the .p12 i have this one ( a little bit different but always probs on the Decrypt ): Decoded PFX Version: 3 AuthSafes has 2 SafeContents AuthSafes verifies correctly. org.mozilla.jss.crypto.BadPaddingException: Padding octet is less than 1 at org.mozilla.jss.crypto.Cipher.unPad(Cipher.java:215) at org.mozilla.jss.pkcs7.EncryptedContentInfo.decrypt(EncryptedContentInfo.java:291) at org.mozilla.jss.pkcs12.AuthenticatedSafes.getSafeContentsAt(AuthenticatedSafes.java:179) at proto.jss.pkcs12.main(pkcs12.java:161) I have try some other tips but i always have an error... If someone has encounter this prob one day or if u think i have miss something during installation or other( Bad Certificate Format for JSS)... All message are welcome... Thx u very much... Cheers Florian Proch ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
