User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030827 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030827 Mozilla cannot work with a certificate containing only the non-repudiation key usage bit. It is possible to import such certificates and PKCS#12 files respectively, but those certificate cannot be verified by Mozilla. If I import a certificate which is identical except that the key usage bit digital signature is also set, there are no problems to verfiy the certificate or sign an email with Mozilla. Reproducible: Always Steps to Reproduce: 1. Import self signed root cert and subordinate CA cert and edit trust level. 2. Import pkcs#12 file with certificate which has only the non repudiation key usage bit 3. View certificate Actual Results: The certificate viewer says: Could not verify this certificate for unknown reasons. Expected Results: Verify this certificate for the use "Email Signer Certificate" and the certificate manager should show the purpose "Sign" for this certificate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please provide a test cert.
The NSS libraries used by Mozilla make no use of non-reudiation certs. They are not used in SSL, SMIME or code signing, the three pricipal uses of certs/PKI in mozilla, at least not at the present time. Changing mozilla to use NR certs means determining where in SSL, SMIME and/or code signing theyy would play a part, and then writing a LOT of new code (I suspect) to implement that. So, I think this bug wants to be a request for enhancement, but it should specify exactly in what uses (e.g. SSL, etc.) it would be used, and perhaps could cite the standards and the relevant pages or sections of those standards. So, submittor, please add a comment making clear what you want to see such a cert (NR-only) used for in mozilla, and citing the relevant standards. Thanks.
Severity: normal → enhancement
Summary: Mozilla cannot work with a certificate containing only the non-repudiation key usage bit. → Support non-repudiation-only certs
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Here is a test certificate (incl. root- and level1-CA-certificate): root: -----BEGIN CERTIFICATE----- MIIEUTCCAzmgAwIBAgIPAP7dAQAAGQ34CCTCIXqIMA0GCSqGSIb3DQEBBQUAMEwx CzAJBgNVBAYTAkRFMRowGAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzEhMB8GA1UE CxMYUHJlLVByb2R1Y3Rpb24gQ2xhc3MzIENBMB4XDTAzMDgxNDEwMDU1OFoXDTEz MDkzMDIzNTk1OVowTDELMAkGA1UEBhMCREUxGjAYBgNVBAoTEVRDIFRydXN0Q2Vu dGVyIEFHMSEwHwYDVQQLExhQcmUtUHJvZHVjdGlvbiBDbGFzczMgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwbyh+jQjPwBBVHszdSyBVYf2JDGiw YmgBWvSWGzon8xhh3gL/gZfoGKFMu7QfgkQGbUzR60YokxlW60YbSAI1+KrMDNen wtU5+ErabhW5tWPtCSredTfI0+Awd72RRk8yh1U6O0OIvPsKqv8s436RzA0TfMDz ZAzDtmlfOuMvIBk/g7ejyjNlj4pNz/yaNNhK/i3I8ehNIa1QxlTP7bL/UTmMSb7S Q+3yTMqI8cMvejC0DnrUo2OnTrKUXFieeriEbV46OyUtli/4zThCUnaZMwJaJ+9w Ai+t+XqNmmSHBVlC42mCEAZyJMRqmvfAoXSZ2b522AHwzOXp8v4wCPvZAgMBAAGj ggEuMIIBKjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQUtikpBQz/kgHCcDJPrHnTcD3xnKMwgecGA1UdHwSB3zCB3DCB2aCB1qCB04Y1 aHR0cDovL3d3dy5wcC50cnVzdGNlbnRlci5kZS9jcmwvdjIvcHJlcHJvZENsYXNz My5jcmyGgZlsZGFwOi8vd3d3LnBwLnRydXN0Y2VudGVyLmRlL0NOPVByZS1Qcm9k dWN0aW9uJTIwQ2xhc3MlMjAzJTIwQ0EsTz1UQyUyMFRydXN0Q2VudGVyJTIwQUcs T1U9cm9vdGNlcnRzLERDPXRydXN0Y2VudGVyLERDPWRlP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT8wDQYJKoZIhvcNAQEFBQADggEBAGhrYQ3aPd+DgqgV 5kOQStPDuiUGDViQEKE5bFhjb1zYVNNZibsS9IY9CA3sJwufnB1cdHU6By1R5sLr Z4lMJPwJW8tmnwGlk1n3kD5TMMfi9TleNXuYeXeo1QWKNwAl9FgwtSo8bnVHQFbC +8t0f9jXjfNhms9F/LMxz/7zl2vvTWX4jcN9X5HzHYU4RsC9a67w5U1gvpURplvs /zzSr+NtqvR5FvrXlk/ZQ0zMM9LzoFrnrSWeX+euYlVubCvjvTlSVgZl3qD9pn4P qU0VJyRHJD5ou0yc6Z67RzxcNYcon+zp/+R9n25mf+J1bgIczTq79iB9oHczJhkK bv15RXE= -----END CERTIFICATE----- level1-CA-certificate: -----BEGIN CERTIFICATE----- MIIFWzCCBEOgAwIBAgIPAOn8AQAAGTKU7OVGrtYSMA0GCSqGSIb3DQEBBQUAMEwx CzAJBgNVBAYTAkRFMRowGAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzEhMB8GA1UE CxMYUHJlLVByb2R1Y3Rpb24gQ2xhc3MzIENBMB4XDTAzMDgxNDEwMDgzM1oXDTEz MDkzMDIzNTk1OVowTzELMAkGA1UEBhMCREUxGjAYBgNVBAoTEVRDIFRydXN0Q2Vu dGVyIEFHMSQwIgYDVQQLExtQcmUtUHJvZHVjdGlvbiBDbGFzczMgTDEgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCol0lBCeDuuJ0f8j4emA/T3bNY yR0NvS/A3ad7CWvFPrCDoEYPZvKIIwQ59Swto3F/84OXtslot4sy9BChqYVWd0UA D0K3e35Q9r/jOwtzPB1Qip9WAT/CP7DZfjijHJAgg1E9F9F/mpvdPmfBmmIu1QpF 6xYsvuBl4POnTmxxtJ69En/E7d+Ckf2ziluZaK/GRfnDaZCk+NKefD6dn+1D6DEE BDZ60r+N2HMr+9rTGeRbsELUNv4lN+TUUq3u5Oz7XfLTFYJhj91FFms5JHLnS4lO OVLb6ALgk7fmgqsoMHH+iz1lOHUWEOEv1WY2O6AYj7CK7/Z3rhXXrzE3vKTHAgMB AAGjggI1MIICMTCBmwYDVR0SBIGTMIGQhoGNbGRhcDovL3d3dy5wcC50cnVzdGNl bnRlci5kZS9DTj1QcmUtUHJvZHVjdGlvbiUyMENsYXNzJTIwMyUyMENBLE89VEMl MjBUcnVzdENlbnRlciUyMEFHLE9VPXJvb3RjZXJ0cyxEQz10cnVzdGNlbnRlcixE Qz1kZT9jYUNlcnRpZmljYXRlP2Jhc2U/MB8GA1UdIwQYMBaAFLYpKQUM/5IBwnAy T6x503A98ZyjMA8GA1UdEwEB/wQFMAMBAf8wRgYDVR0gBD8wPTA7BgkqghQALAEB AQMwLjAsBggrBgEFBQcCARYgaHR0cDovL3d3dy5wcC50cnVzdGNlbnRlci5kZS9j cHMwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ4+/Ccv0ZWMEqYz2tBEmPYsAW2 aTCB5wYDVR0fBIHfMIHcMIHZoIHWoIHThjVodHRwOi8vd3d3LnBwLnRydXN0Y2Vu dGVyLmRlL2NybC92Mi9wcmVwcm9kQ2xhc3MzLmNybIaBmWxkYXA6Ly93d3cucHAu dHJ1c3RjZW50ZXIuZGUvQ049UHJlLVByb2R1Y3Rpb24lMjBDbGFzcyUyMDMlMjBD QSxPPVRDJTIwVHJ1c3RDZW50ZXIlMjBBRyxPVT1yb290Y2VydHMsREM9dHJ1c3Rj ZW50ZXIsREM9ZGU/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkq hkiG9w0BAQUFAAOCAQEAT17qtv+5QIXED3fzRAH4tJafZNxhqG0Q6NVEQZHFRTEl pWBvR0TTU7rcrq77svl79lY9tYcWPgAEA/8x5ie9kGK6qiph8RCdc3s6iyI6Ocqa mr3XlT6MVjgQ7W74yC6vIiovblhTnsgcAmNYHcW5FxmQjWOzagUEXnfBhJLzQa/K Srl2HmaIlZu+AMnhjGoLexDWjYGwaPmkHoggNPd2KQkAJrm2xEJJ87m+MlRtKHOW zIozGPg1ccQkmtutMhh9mp6ULqovFLXacCPFmLYt0bN/d8Y37Ur5MhKFohugWHtm gi5+rc5RU0wD4n4lI/3tEQ2X4kmh6zyAxMs7jMf25w== -----END CERTIFICATE----- ocsp-signer-certificate: -----BEGIN CERTIFICATE----- MIIF4DCCBMigAwIBAgIPAOrPAQAAGR+Fgsemjd1TMA0GCSqGSIb3DQEBBQUAME8x CzAJBgNVBAYTAkRFMRowGAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzEkMCIGA1UE CxMbUHJlLVByb2R1Y3Rpb24gQ2xhc3MzIEwxIENBMB4XDTAzMDgxNTA5MzE0MFoX DTEzMDgxNDA5MzE0MFowgY8xCzAJBgNVBAYTAkRFMRAwDgYDVQQHEwdIYW1idXJn MRowGAYDVQQKExFUQyBUcnVzdENlbnRlciBBRzE0MDIGA1UECxMrUHJlLVByb2R1 Y3Rpb24gT0NTUCBSZXNwb25kZXIgR3JvdXAgQ2xhc3MgMzEcMBoGA1UEAxMTVEMg T0NTUCBSZXNwb25kZXIgSTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMqD097AO6bb+jHY+Dy8TF+u5MQBYNINj3xIh6nUnbGyz609bYHnKOQuqMFvMkXi WlTfnxhynrriDKz76M98YDh2UKwHOyQZjivPw+42xCkPDqeHu/Vv9QECO+c+t3vz mlL403zXGroUdLAGDGiKuk+rVM9IaHoYmfgiU7JVewc2DZXf0zwKNAo5DGJW8OkX 7/BwtE7E+QTo+wuAHwLwle2BFqLpVNyQ/FZItPla1zjr+Mju3gneG55lf3Q0jYXb WvZwoAxleglIwcby908TJCM2zNS7FsiWp3hYrZabluS83XFBTlEWN4mDFqIZ4exQ 3KoM9UXP9V+DwHju18Bl068CAwEAAaOCAnYwggJyMIGgBgNVHRIEgZgwgZWGgZJs ZGFwOi8vd3d3LnBwLnRydXN0Y2VudGVyLmRlL0NOPVByZS1Qcm9kdWN0aW9uJTIw Q2xhc3MlMjAzJTIwTDElMjBDQSxPPVRDJTIwVHJ1c3RDZW50ZXIlMjBBRyxPVT1y b290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/Y2FDZXJ0aWZpY2F0ZT9iYXNl PzAfBgNVHSMEGDAWgBQ4+/Ccv0ZWMEqYz2tBEmPYsAW2aTAMBgNVHRMBAf8EAjAA MEYGA1UdIAQ/MD0wOwYJKoIUACwBAQEDMC4wLAYIKwYBBQUHAgEWIGh0dHA6Ly93 d3cucHAudHJ1c3RjZW50ZXIuZGUvY3BzMA4GA1UdDwEB/wQEAwIGQDAdBgNVHQ4E FgQURza/5hq007WDlgfDmPzK5HpGT/Awge4GA1UdHwSB5jCB4zCB4KCB3aCB2oY3 aHR0cDovL3d3dy5wcC50cnVzdGNlbnRlci5kZS9jcmwvdjIvcHJlcHJvZENsYXNz M0wxLmNybIaBnmxkYXA6Ly93d3cucHAudHJ1c3RjZW50ZXIuZGUvQ049UHJlLVBy b2R1Y3Rpb24lMjBDbGFzcyUyMDMlMjBMMSUyMENBLE89VEMlMjBUcnVzdENlbnRl ciUyMEFHLE9VPXJvb3RjZXJ0cyxEQz10cnVzdGNlbnRlcixEQz1kZT9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/MBMGA1UdJQQMMAoGCCsGAQUFBwMJMCEG A1UdEQQaMBiBFnN1cHBvcnRAdHJ1c3RjZW50ZXIuZGUwDQYJKoZIhvcNAQEFBQAD ggEBACLZz+v/tEtj6RqCL4k474zyGaNdfnEroP0/Mlr6VgIFkeTdZn1Bn9anMtSp eNG8NY/RjLooEA06t0MMSApI/7LEJwb/vbr559rx6BEcRFE/nKssvzIrp5yradFX CIrXXJB4x2SQXbcJM/ZGwAmdDsS6nXS5KcUQF9LicB3IcR/N50MkyuksMfFcfRvO 9ZXVB8KHplEv/67PNr8QNsMt26EI7Mj/HpTHRIwYxrEBNPQT9g3rqYuhvgqG1q+9 vtaSCyN1NU7U7Dytk2ifXdunbA8AZ/P1GU1iyepFOAD3NSghzxF/HJsZLmWmdgIV 689TMZFqagmwDaT6pWS2KuEFITc= -----END CERTIFICATE----- Maybe this is not really a bug, but a request for enhancement. I think, there are a lot of discussions in progress about the use of the keyUsage NonRepudiation (e.g. at the pkix-mailing list). So I cannot cite the pages of the relevant standard where it says that NR-only certs should or must be used. Nevertheless there are applications which uses NR-only-certs. E.g. an OCSP-Responder which uses an certificate with keyUsasge nonRepudiation and ExtendedKeyUsage 'OCSP Signing'. Now it is not possible to verify an OCSPResponse of such an OCSP-responder with Mozilla. But I expect that Mozilla should be able to verify such things.
cite a reproducible example of a standard protocol failing with proper use of NR certs. Your OCSP example, if real, would be a good start.
See, saying "NSS should use NR-only certs" is like saying "NSS should use SHA-512 hashes" (which someone did about a year ago). It's a technology, but not a protocol. I added the 3 new SHA hash algorithms to NSS, and now they just sit there, unused, because SSL and SMIME and OCSP do not use them. NSS implements protocols, like SMIME and SSL and OCSP, and uses certs as defined in those protocol standards, IINM. People would LIKE it if those protocol standards included new technologies, but (AFAIK) they don't. So, until they do, adding new technology just adds dead code to NSS. I predict that action will be taken on this bug right AFTER some revision to SSL/TLS or SMIME codes out that explains how NR-only certs are to be used in it, not before. When this bug says "Use NR-only certs ACCORDING TO THE NEW IETF RFC-xxxx", then action will happen.
(In reply to comment #7) > See, saying "NSS should use NR-only certs" is like saying "NSS should use > SHA-512 hashes" (which someone did about a year ago). It's a technology, > but not a protocol. > > I added the 3 new SHA hash algorithms to NSS, and now they just sit there, > unused, because SSL and SMIME and OCSP do not use them. > > NSS implements protocols, like SMIME and SSL and OCSP, and uses certs as > defined in those protocol standards, IINM. People would LIKE it if those > protocol standards included new technologies, but (AFAIK) they don't. > So, until they do, adding new technology just adds dead code to NSS. > > I predict that action will be taken on this bug right AFTER some revision > to SSL/TLS or SMIME codes out that explains how NR-only certs are to be > used in it, not before. When this bug says "Use NR-only certs ACCORDING > TO THE NEW IETF RFC-xxxx", then action will happen. According the the ISIS-MTT Specification which is based on RFC and ETSI, Non-Repudiation only certs must be used for ocsp-responder certificates and should be used for End-Entity certificates which are meant for usage of content-commitment. Page 33: "OCSP responder certificates: the crlSign bit and only this bit MUST be set, if the CA uses the corresponding key to sign CRLs. OCSP responders are issued end-entity certificates with only the nonRepudiation bit set and including the ExtendedKeyUsage extension with only the id-kp-OCSPSigning option" and End entity user certificates: all permitted purposes MUST be stated in end entity certificates, so that client components are able to find the certificate intended for a specific action. In particular, it is RECOMMENDED that CAs issue separate certificates for the purposes of non-repudiation (only nonRepudiation set), authentication(only signature bit set) and encryption (only DataEncipherment and keyEncipherment set). English Version of the whole specification can be found at http://www.teletrust.de/Dokumente%5CISIS-MTT_Core_Specification_v1.1.pdf
I don't know why this bug was filed against security UI, since it's not a UI problem. NSS bug 240456 was filed about this problem in April 2004, and was fixed in NSS 3.10. Products incorporating NSS 3.10 or later should not have any problems with NR certs. I'm hereby asking Katrin Selchau-Hansen, the reporter of this bug, to confirm that the problem is fixed in browsers with NSS 3.10. If so, I will mark this bug as a duplicate of bug 240456.
Katrin Selchau-Hansen: to verify that the bug has been fixed with a Mozilla browser, you must use Firefox 1.5 or later.
If you need to verify the fix with an email client, use Thunderbird 1.5 (the current pre-release is RC2) or later. No Mozilla Application Suite ("SeaMonkey") release uses NSS 3.10.
Bug 240456 is resolved. Is there additional change (such as UI) requested by this bug? Or is this merely a dup of bug 240456 ?
Depends on: 240456
Comment on attachment 438218 [details] [diff] [review] Non-repudiation patch Philipp: thanks for the patch. Is the goal of your patch to prevent NSS from using non-repudiation-only certs for SSL client authentication? I just wanted to make sure I understand the intention of your patch correctly. I noticed that you didn't modify the certUsageSSLClient case in that switch statement.
The problem with NR certs is that different countries have different definitions of the correct and proper usage of these certificates. If we make a change to make one user in one country happy, we make users in another country unhappy. We have been around this circle several times before. We've received numerous patches, and have committed some, only to receive bug reports from other users complaining that the change was incorrect. Each would-be contributor is certain that his idea of the "right way" is the only definition of correct behavior. I think we should avoid making any more trips around this circle.
Wan-Teh Chang: Exactly: That's what the patch should do. Only allowing NR certificates for s/mime, OCSP,.. but not for client authentication. the problem is that most servers don't accept a certificate without digitalSignature in keyusage and it'll result in an ugly ssl error that a normal user doesn't understand.
Comment on attachment 438218 [details] [diff] [review] Non-repudiation patch r=wtc. Please make the following changes. 1. In certdb.c: In CERT_KeyUsageAndTypeForCertUsage, please add a comment to the certUsageSSLClient case to note that KU_NON_REPUDIATION is not acceptable for authentication. In CERT_CheckKeyUsage, please remove the local variable certKeyUsage; replace it with cert->keyUsage. Remove the comment: /* Accept either signature or non repudation. */ because it is redundant with a previous comment. 2. In certt.h: > /* This value will not occur in certs. It is used internally for the case >+ * when the key type is not know ahead of time and either digital signature or >+ * non repudiation are the correct value based on key type >+ */ >+#define KU_DIGITAL_SIGNATURE_OR_NON_REPUDIATION (0x2000) The key type is irrelevant to this issue. So please change the second sentence in the comment to: It is used internally for the case when either digital signature or non-repudiation is the correct value.
Philip can you update the patch to match comment 17 ?
Assignee: nobody → debian
Ludovic: if Philip doesn't reply in a week, please remind me to update his patch. I can make those changes for him. Thanks.
(In reply to comment #19) > Ludovic: if Philip doesn't reply in a week, please remind me to > update his patch. I can make those changes for him. Thanks. Wan-Teh : reminder :-)
Ludovic/Wan-Teh: Sorry for the delay. I will upload the updated patch ASAP (with the next hour)
Created attachment 495514 [details] [diff] [review] Non-repudiation patch with additional fixes and comments
Comment on attachment 495514 [details] [diff] [review] Non-repudiation patch with additional fixes and comments setting the review flag just in caes :D
Created attachment 496044 [details] [diff] [review] Non-repudiation patch v3, by Philipp Hug This is essentially Philipp Hug's patch v2 (attachment 495514 [details] [diff] [review]). I only made minor punctuation changes to some comments. Bob, Nelson, please review.
Comment on attachment 496044 [details] [diff] [review] Non-repudiation patch v3, by Philipp Hug r+ though I'm curious why the previous code didn't work? If we asked for digitial signature, then we would accept either digital signature and non repudiation. The patch is better because it will no longer accept non-repudiation in the SSL client auth cert. bob
Attachment #496044 - Flags: superreview?(rrelyea) → superreview+
OK, after reviewing the comments more, I now understand the purpose is exactly that (not accept non-repudiation in ssl client auth certs).
Bob: I guess the idea of the patch is that Mozilla's client cert selection dialog should not present a non-repudiation-only cert. I remember Mozilla tries to do that in PSM. Perhaps the PSM code isn't working perfectly, so they want to do this at the NSS level.
Component: Security: UI → Libraries
Product: Core → NSS
QA Contact: ui → libraries
Target Milestone: --- → 3.12.10
Version: Other Branch → 3.12
Comment on attachment 496044 [details] [diff] [review] Non-repudiation patch v3, by Philipp Hug Behold, the slippery slope onto which our descent begins. As you know, there are numerous different country standards for the use of NR, that are mutually exclusive. No one implementation can satisfy them all. Proponents of each one insist that NSS be made to conform one particular standards, insisting that it is the ONE TRUE WAY (tm). When you accede to one, you must thereafter explain why you will not accede to all others.
Attachment #496044 - Flags: review?(nelson) → review+
What's the state of this bug? Please either check it in, or remove the checkin-needed keyword.
Status: NEW → ASSIGNED
Whiteboard: [patchlove][needs new assignee?]
Created attachment 549231 [details] [diff] [review] Non-repudiation patch v4, by Philipp Hug I forgot to check this patch in. Sorry about that. Patch checked in on the NSS trunk (NSS 3.13). Checking in certdb.c; /cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v <-- certdb.c new revision: 1.115; previous revision: 1.114 done Checking in certt.h; /cvsroot/mozilla/security/nss/lib/certdb/certt.h,v <-- certt.h new revision: 1.55; previous revision: 1.54 done
Attachment #496044 - Attachment is obsolete: true
Attachment #438218 - Attachment description: Non-repudiation patch (wtc: needs changes and an additional review by nelson or rrelyea before checkin) → Non-repudiation patch
Created attachment 549505 [details] [diff] [review] Follow RFC 5280 guidance I studied the relevant text in RFC 5280 and TLS 1.2 (RFC 5246). Both state or imply that SSL client authentication certificates should have the digitalSignature bit in the key usage extension, if the extension exists. RFC 5280 also says code signing needs digitalSignature, as opposed to "digitalSignature and/or nonRepudiation", so I changed the certUsageObjectSigner case back to KU_DIGITAL_SIGNATURE. Bob, Nelson, please review. Thanks.
Attachment #549505 - Flags: superreview? → superreview?(nelson)
Comment on attachment 549505 [details] [diff] [review] Follow RFC 5280 guidance r+ I like the idea that we point to an RFC for these changes. bob
Attachment #549505 - Flags: review?(rrelyea) → review+
Comment on attachment 549231 [details] [diff] [review] Non-repudiation patch v4, by Philipp Hug This patch was also checked in on the NSS 3.12 branch (NSS 3.12.11) last week (2011/07/28). certdb.c, rev. 184.108.40.206 certt.h, rev. 220.127.116.11
Comment on attachment 549505 [details] [diff] [review] Follow RFC 5280 guidance Patch checked in on the NSS trunk (NSS 3.13) and NSS_3_12_BRANCH (NSS 3.12.11). Checking in certdb.c; /cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v <-- certdb.c new revision: 1.116; previous revision: 1.115 done Checking in certdb.c; /cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v <-- certdb.c new revision: 18.104.22.168; previous revision: 22.214.171.124 done
Severity: enhancement → normal
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
OS: Windows NT → All
Priority: -- → P1
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [patchlove][needs new assignee?]
You need to log in before you can comment on or make changes to this bug.