Support non-repudiation-only certs

RESOLVED FIXED in 3.12.11

Status

NSS
Libraries
P1
normal
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: Katrin Selchau-Hansen, Assigned: Wan-Teh Chang)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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.
Confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

15 years ago
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.

Updated

15 years ago
Severity: normal → enhancement
Summary: Mozilla cannot work with a certificate containing only the non-repudiation key usage bit. → Support non-repudiation-only certs

Comment 4

15 years ago
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
(Reporter)

Comment 5

15 years ago
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.

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Comment 8

13 years ago
(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.
(Assignee)

Comment 10

13 years ago
Katrin Selchau-Hansen: to verify that the bug has been
fixed with a Mozilla browser, you must use Firefox 1.5
or later.
(Assignee)

Comment 11

13 years ago
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
QA Contact: bmartin → ui

Comment 13

8 years ago
Created attachment 438218 [details] [diff] [review]
Non-repudiation patch
(Assignee)

Comment 14

8 years ago
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.

Comment 16

8 years ago
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.
Attachment #438218 - Flags: review?(wtc)
(Assignee)

Comment 17

8 years ago
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.
Attachment #438218 - Attachment description: Non-repudiation patch → Non-repudiation patch (wtc: needs changes and an additional review by nelson or rrelyea before checkin)
Attachment #438218 - Flags: review?(wtc) → review+
Philip can you update the patch to match comment 17 ?
Assignee: nobody → debian
(Assignee)

Comment 19

8 years ago
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 :-)

Comment 21

8 years ago
Ludovic/Wan-Teh:
Sorry for the delay. I will upload the updated patch ASAP (with the next hour)

Comment 22

8 years ago
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
Attachment #495514 - Flags: review?(wtc)

Updated

8 years ago
Assignee: debian → wtc
(Assignee)

Comment 24

8 years ago
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.
Attachment #438218 - Attachment is obsolete: true
Attachment #495514 - Attachment is obsolete: true
Attachment #496044 - Flags: superreview?(rrelyea)
Attachment #496044 - Flags: review?(nelson)
Attachment #495514 - Flags: review?(wtc)

Comment 25

8 years ago
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+

Comment 26

8 years ago
OK, after reviewing the comments more, I now understand the purpose is exactly that (not accept non-repudiation in ssl client auth certs).
(Assignee)

Comment 27

8 years ago
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
Version: 3.12 → 3.3
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+
Keywords: checkin-needed

Comment 29

7 years ago
What's the state of this bug?

Please either check it in, or remove the checkin-needed keyword.
Status: NEW → ASSIGNED
Keywords: checkin-needed
Whiteboard: [patchlove][needs new assignee?]
(Assignee)

Updated

7 years ago
Target Milestone: 3.12.10 → 3.12.11
(Assignee)

Comment 30

7 years ago
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
(Assignee)

Updated

7 years ago
Attachment #438218 - Attachment description: Non-repudiation patch (wtc: needs changes and an additional review by nelson or rrelyea before checkin) → Non-repudiation patch
(Assignee)

Comment 31

7 years ago
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?
Attachment #549505 - Flags: review?(rrelyea)
(Assignee)

Updated

7 years ago
Attachment #549505 - Flags: superreview? → superreview?(nelson)

Comment 32

7 years ago
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+
(Assignee)

Updated

7 years ago
Duplicate of this bug: 558284
(Assignee)

Comment 34

7 years ago
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. 1.104.2.4
certt.h, rev. 1.54.2.1
(Assignee)

Comment 35

7 years ago
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: 1.104.2.5; previous revision: 1.104.2.4
done
(Assignee)

Updated

7 years ago
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?]
(Assignee)

Updated

7 years ago
Attachment #549505 - Flags: superreview?(nelson)
You need to log in before you can comment on or make changes to this bug.