Open Bug 277797 Opened 20 years ago Updated 2 years ago

add support for qcStatement extensions

Categories

(NSS :: Libraries, enhancement, P4)

Product:
NSS
Component:
Libraries
Platform:
x86
Windows XP
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: varga.viktor, Unassigned)

References

Details

I attached 4 root CA certificate, at the bottom of this bug report. They are the certificates of Netlock, we are CA in Hungary. The first certificate has a field, qcStatement, which is set critical. This is the Hungarian regulation for this level of certificate, but we think, this is why it cann't be imported. The others can be importzed fine. These certificetes are working with the IE (already in), Opera (importable), but don't work with the Mozilla product line (Mozilla browser, Firefox browser, Thunderbird mail client was tested.) For further information, fell free to contact me: Viktor Varga varga_v@netlock.net +36-20-988196 www.netlock.net (When it will work with the Mozilla product line, we want to move forward, and we would like to include them into the default repository. of-course :) ---------- Qualified (Class QA) -----BEGIN CERTIFICATE----- MIIH+zCCBuOgAwIBAgIBEDANBgkqhkiG9w0BAQUFADCByTELMAkGA1UEBhMCSFUx ETAPBgNVBAcTCEJ1ZGFwZXN0MScwJQYDVQQKEx5OZXRMb2NrIEhhbG96YXRiaXp0 b25zYWdpIEtmdC4xGjAYBgNVBAsTEVRhbnVzaXR2YW55a2lhZG9rMUIwQAYDVQQD EzlOZXRMb2NrIE1pbm9zaXRldHQgS296amVneXpvaSAoQ2xhc3MgUUEpIFRhbnVz aXR2YW55a2lhZG8xHjAcBgkqhkiG9w0BCQEWD2luZm9AbmV0bG9jay5odTAeFw0w MzAzMzAwMTQ3MTFaFw0yMjEyMTUwMTQ3MTFaMIHJMQswCQYDVQQGEwJIVTERMA8G A1UEBxMIQnVkYXBlc3QxJzAlBgNVBAoTHk5ldExvY2sgSGFsb3phdGJpenRvbnNh Z2kgS2Z0LjEaMBgGA1UECxMRVGFudXNpdHZhbnlraWFkb2sxQjBABgNVBAMTOU5l dExvY2sgTWlub3NpdGV0dCBLb3pqZWd5em9pIChDbGFzcyBRQSkgVGFudXNpdHZh bnlraWFkbzEeMBwGCSqGSIb3DQEJARYPaW5mb0BuZXRsb2NrLmh1MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx1Ilstg91IRVCacbvWy5FPSKAtt2/Goq eKvld/Bu4IwjZ9ulZJm53QE+b+8tmjwi8F3JV6BVQX/yQ15YglMxZc4e8ia6AFQe r7C8HORSjKAyr7c3sVNnaHRnUPYtLmTeriZ539+Zhqurf4XsoPuAzPS4DB6TRWO5 3Lhbm+1bOdRfYrCnjnxmOCyqsQhjF2d9zL2z8cM/z1A57dEZgxXbhxInlrfa6uWd vLrqOU+L73Sa58XQ0uqGURzk/mQIKAR5BevKxXEOC++r6uwSEaEYBTJp0QwsGj0l mT+1fMptsK6ZmfoIYOcZwvK9UdPM0wKswREMgM6r3JSda6M5UzrWhQIDAMV9o4ID 6jCCA+YwEgYDVR0TAQH/BAgwBgEB/wIBBDAOBgNVHQ8BAf8EBAMCAQYwGwYIKwYB BQUHAQMBAf8EDDAKMAgGBgQAjkYBATCCA6EGCWCGSAGG+EIBDQSCA5IWggOORklH WUVMRU0hIEV6ZW4gdGFudXNpdHZhbnkgYSBOZXRMb2NrIEtmdC4gTWlub3NpdGV0 dCBTem9sZ2FsdGF0YXNpIFN6YWJhbHl6YXRhYmFuIGxlaXJ0IGVsamFyYXNvayBh bGFwamFuIGtlc3p1bHQuIEEga2lib2NzYXRvdHQgdGFudXNpdHZhbnlob3ogdGFy dG96byBtYWdhbmt1bGNzIGEgam9nc3phYmFseWkgcmVuZGVsa2V6ZXNla25layBt ZWdmZWxlbG8gQml6dG9uc2Fnb3MgQWxhaXJhcyBMZXRyZWhvem8gRXN6a296YmVu IChCQUxFKSBrZXN6dWx0LiBBIG1pbm9zaXRldHQgZWxla3Ryb25pa3VzIGFsYWly YXMgam9naGF0YXMgZXJ2ZW55ZXN1bGVzZW5laywgdmFsYW1pbnQgZWxmb2dhZGFz YW5hayBmZWx0ZXRlbGUgYSBNaW5vc2l0ZXR0IFN6b2xnYWx0YXRhc2kgU3phYmFs eXphdGJhbiwgYXogQWx0YWxhbm9zIFN6ZXJ6b2Rlc2kgRmVsdGV0ZWxla2JlbiBl bG9pcnQgZWxsZW5vcnplc2kgZWxqYXJhcyBtZWd0ZXRlbGUuIEEgZG9rdW1lbnR1 bW9rIG1lZ3RhbGFsaGF0b2sgYSBodHRwczovL3d3dy5uZXRsb2NrLmh1L2RvY3Mv IGNpbWVuIHZhZ3kga2VyaGV0b2sgYXogaW5mb0BuZXRsb2NrLm5ldCBlLW1haWwg Y2ltZW4uIFdBUk5JTkchIFRoaXMgY2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVk IGFzIGEgcXVhbGlmaWVkIGNlcnRpZmljYXRlLiBUaGUgY29ycmVzcG9uZGluZyBw cml2YXRlIGtleSBoYXMgYmVlbiBnZW5lcmF0ZWQgb24gYSBTZWN1cmUgU2lnbmF0 dXJlIENyZWF0aW9uIERldmljZSAoU1NDRCkuIFRoZSBpc3N1YW5jZSBhbmQgdGhl IHVzZSBvZiB0aGlzIGNlcnRpZmljYXRlIGFyZSBzdWJqZWN0IHRvIHRoZSBOZXRM b2NrIFF1YWxpZmllZCBDUFMgYXZhaWxhYmxlIGF0IGh0dHBzOi8vd3d3Lm5ldGxv Y2suaHVkb2NzLyBvciBieSBlLW1haWwgYXQgaW5mb0BuZXRsb2NrLm5ldDANBgkq hkiG9w0BAQUFAAOCAQEAFQXbp9UbAIBzZWkrPzbZCnSA7wgiCmHKxmWCnXBm8UTU Ia3UuOyTzpS6msdUFkLMIjpUPdDEjsA3qcxKIeLzAQATjYmp7mADio+uWv9RunTi ZOkaNuoa7j/y57XZCx/LUHtpcEH1KY2LZwOGi5TbkmYfE+b7IiFoTfChJ9RYkoGi v1OVQ1JfzgGB/sd1QeMzFDt2c6tqyMGtNzOMqAU37DGfC2spiS2g4UD15q1f5MBs OC2F1gRx9/q83zee0EGzDzWvxkYWXtIFfd49RvdRvG4rEHPPHTtaW9R6YDKZrj9i ICUh7wvfwzX+Ozax6pdMqxQzzlC4f1p2HILEBjeEHQ== -----END CERTIFICATE----- Notary (Class A) -----BEGIN CERTIFICATE----- MIIGfTCCBWWgAwIBAgICAQMwDQYJKoZIhvcNAQEEBQAwga8xCzAJBgNVBAYTAkhV MRAwDgYDVQQIEwdIdW5nYXJ5MREwDwYDVQQHEwhCdWRhcGVzdDEnMCUGA1UEChMe TmV0TG9jayBIYWxvemF0Yml6dG9uc2FnaSBLZnQuMRowGAYDVQQLExFUYW51c2l0 dmFueWtpYWRvazE2MDQGA1UEAxMtTmV0TG9jayBLb3pqZWd5em9pIChDbGFzcyBB KSBUYW51c2l0dmFueWtpYWRvMB4XDTk5MDIyNDIzMTQ0N1oXDTE5MDIxOTIzMTQ0 N1owga8xCzAJBgNVBAYTAkhVMRAwDgYDVQQIEwdIdW5nYXJ5MREwDwYDVQQHEwhC dWRhcGVzdDEnMCUGA1UEChMeTmV0TG9jayBIYWxvemF0Yml6dG9uc2FnaSBLZnQu MRowGAYDVQQLExFUYW51c2l0dmFueWtpYWRvazE2MDQGA1UEAxMtTmV0TG9jayBL b3pqZWd5em9pIChDbGFzcyBBKSBUYW51c2l0dmFueWtpYWRvMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvHSMD7tM9DceqQWC2ObhbHDqeLVu0ThEDaiD zl3S1tWBxdRL51uUcCbbO51qTGL3cfNk1mE7PetzozfZz+qMkjvN9wfcZnSX9EUi 3fRc4L9t875lM+QVOr/bmJBVOMTtplVjC7B4BPTjbsE/jvxReB+SnoPC/tmwqcm8 WgD/qaiYdPv2LD4VOQ22BFWoDpggQrOxJa1+mm9dU7GrDPzr4PN6s6iz/0b2Y6LY Oph7tqyF/7AlT3Rj5xMHpQqPBffAZG9+pyeAlt7ULoZgx2srXnN7F+eRP2QM2Esi NCubMvJIH5+hCoR64sKtlz2O1cH5VqNQ6ca0+pii7pXmKgOM3wIDAQABo4ICnzCC ApswDgYDVR0PAQH/BAQDAgAGMBIGA1UdEwEB/wQIMAYBAf8CAQQwEQYJYIZIAYb4 QgEBBAQDAgAHMIICYAYJYIZIAYb4QgENBIICURaCAk1GSUdZRUxFTSEgRXplbiB0 YW51c2l0dmFueSBhIE5ldExvY2sgS2Z0LiBBbHRhbGFub3MgU3pvbGdhbHRhdGFz aSBGZWx0ZXRlbGVpYmVuIGxlaXJ0IGVsamFyYXNvayBhbGFwamFuIGtlc3p1bHQu IEEgaGl0ZWxlc2l0ZXMgZm9seWFtYXRhdCBhIE5ldExvY2sgS2Z0LiB0ZXJtZWtm ZWxlbG9zc2VnLWJpenRvc2l0YXNhIHZlZGkuIEEgZGlnaXRhbGlzIGFsYWlyYXMg ZWxmb2dhZGFzYW5hayBmZWx0ZXRlbGUgYXogZWxvaXJ0IGVsbGVub3J6ZXNpIGVs amFyYXMgbWVndGV0ZWxlLiBBeiBlbGphcmFzIGxlaXJhc2EgbWVndGFsYWxoYXRv IGEgTmV0TG9jayBLZnQuIEludGVybmV0IGhvbmxhcGphbiBhIGh0dHBzOi8vd3d3 Lm5ldGxvY2submV0L2RvY3MgY2ltZW4gdmFneSBrZXJoZXRvIGF6IGVsbGVub3J6 ZXNAbmV0bG9jay5uZXQgZS1tYWlsIGNpbWVuLiBJTVBPUlRBTlQhIFRoZSBpc3N1 YW5jZSBhbmQgdGhlIHVzZSBvZiB0aGlzIGNlcnRpZmljYXRlIGlzIHN1YmplY3Qg dG8gdGhlIE5ldExvY2sgQ1BTIGF2YWlsYWJsZSBhdCBodHRwczovL3d3dy5uZXRs b2NrLm5ldC9kb2NzIG9yIGJ5IGUtbWFpbCBhdCBjcHNAbmV0bG9jay5uZXQuMA0G CSqGSIb3DQEBBAUAA4IBAQBIJEb3ulZv+sgoA0BO5TE5ayZrU3/b39/zcT0mwBQO xmd7I6gMc90Bu8bKbjc5VdXHjFYgDigKDtIqpLBJUsY4B/6+CgmM0ZjPytoUMaFP 0jn8DxEsQ8Pdq5PHVT5HfBgaANzze9jyf1JsIPQLX2lS9O74silg6+NJMSEN1rUQ QeJBCWziGppWS3cC9qCbmieH6FUpccKQn0V4GuEVZD3QDtigdp+uxdAu6tYPVuxk f1qbFFgBJ34TUMdrKuZoPL9coAob4Q566eKAw+np9v1sEZ7Q5SgnK1QyQhSCdeZK 8CtmdWOMovsEPoMOmzbwGOQmIMOM8CgHrTwXZoi1/baI -----END CERTIFICATE----- Business (Class B) -----BEGIN CERTIFICATE----- MIIFSzCCBLSgAwIBAgIBaTANBgkqhkiG9w0BAQQFADCBmTELMAkGA1UEBhMCSFUx ETAPBgNVBAcTCEJ1ZGFwZXN0MScwJQYDVQQKEx5OZXRMb2NrIEhhbG96YXRiaXp0 b25zYWdpIEtmdC4xGjAYBgNVBAsTEVRhbnVzaXR2YW55a2lhZG9rMTIwMAYDVQQD EylOZXRMb2NrIFV6bGV0aSAoQ2xhc3MgQikgVGFudXNpdHZhbnlraWFkbzAeFw05 OTAyMjUxNDEwMjJaFw0xOTAyMjAxNDEwMjJaMIGZMQswCQYDVQQGEwJIVTERMA8G A1UEBxMIQnVkYXBlc3QxJzAlBgNVBAoTHk5ldExvY2sgSGFsb3phdGJpenRvbnNh Z2kgS2Z0LjEaMBgGA1UECxMRVGFudXNpdHZhbnlraWFkb2sxMjAwBgNVBAMTKU5l dExvY2sgVXpsZXRpIChDbGFzcyBCKSBUYW51c2l0dmFueWtpYWRvMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCx6gTsIKAjwo84YM/HRrPVG/77uZmeBNwcf4xK gZjupNTKihe5In+DCnVMm8Bp2GQ5o+2So/1bXHQawEfKOml2mrriRBf8TKPV/riX iK+IA4kfpPIEPsgHC+b5sy96YhQJRhTKZPWLgLViqNhr1nGTLbO/CVRY7QbrqHvc Q7GhaQIDAQABo4ICnzCCApswEgYDVR0TAQH/BAgwBgEB/wIBBDAOBgNVHQ8BAf8E BAMCAAYwEQYJYIZIAYb4QgEBBAQDAgAHMIICYAYJYIZIAYb4QgENBIICURaCAk1G SUdZRUxFTSEgRXplbiB0YW51c2l0dmFueSBhIE5ldExvY2sgS2Z0LiBBbHRhbGFu b3MgU3pvbGdhbHRhdGFzaSBGZWx0ZXRlbGVpYmVuIGxlaXJ0IGVsamFyYXNvayBh bGFwamFuIGtlc3p1bHQuIEEgaGl0ZWxlc2l0ZXMgZm9seWFtYXRhdCBhIE5ldExv Y2sgS2Z0LiB0ZXJtZWtmZWxlbG9zc2VnLWJpenRvc2l0YXNhIHZlZGkuIEEgZGln aXRhbGlzIGFsYWlyYXMgZWxmb2dhZGFzYW5hayBmZWx0ZXRlbGUgYXogZWxvaXJ0 IGVsbGVub3J6ZXNpIGVsamFyYXMgbWVndGV0ZWxlLiBBeiBlbGphcmFzIGxlaXJh c2EgbWVndGFsYWxoYXRvIGEgTmV0TG9jayBLZnQuIEludGVybmV0IGhvbmxhcGph biBhIGh0dHBzOi8vd3d3Lm5ldGxvY2submV0L2RvY3MgY2ltZW4gdmFneSBrZXJo ZXRvIGF6IGVsbGVub3J6ZXNAbmV0bG9jay5uZXQgZS1tYWlsIGNpbWVuLiBJTVBP UlRBTlQhIFRoZSBpc3N1YW5jZSBhbmQgdGhlIHVzZSBvZiB0aGlzIGNlcnRpZmlj YXRlIGlzIHN1YmplY3QgdG8gdGhlIE5ldExvY2sgQ1BTIGF2YWlsYWJsZSBhdCBo dHRwczovL3d3dy5uZXRsb2NrLm5ldC9kb2NzIG9yIGJ5IGUtbWFpbCBhdCBjcHNA bmV0bG9jay5uZXQuMA0GCSqGSIb3DQEBBAUAA4GBAATbrowXr/gOkDFOzT4JwG06 sPgzTEdM43WIEJessDgVkcYplswhwG08pXTP2IKlOcNl40JwuyKQ433bNXbhoLXa n3BukxowOR0w2y7jfLKRstE3Kfq51hdcR0/jHTjrn9V7lagonhVK0dHQKwCXoOKS NitjrFgBazMpUIaD8QFI -----END CERTIFICATE-----
Sorry, but i misstyped some words in my bug report. So, only the QA level certificate isn't importable, the others are working and importable fine.
The cert shown above as "Qualified (Class QA)" has an unknown critical extension. Name: OID.1.3.6.1.5.5.7.1.3 Critical: True Data: Sequence { Sequence { OID.0.4.0.1862.1.1 } } NSS doesn't know this extension, and so rejects the cert, as it must do for any unknown critical extension. That behavior (rejecting a cert with an unknown critical extension) is not a bug, and is required by RFC 3280. So, this bug report can be construed as an enhancement request, requesting the support for this particular cert extension be added to NSS. I think it's somewhat unlikely that that will happen soon. PERHAPS if the processing of this extension is trivial, and doesn't require any API additions to NSS, it could be done this year. To that end, please add comments to this bug citing the relevant (hopefully international) standards that define this extension, and the OIDs that go with it, and what must be done to process it correctly.
Assignee: kaie → wtchang
Severity: major → enhancement
Component: Client Library → Libraries
Product: PSM → NSS
QA Contact: bishakhabanerjee
Version: 1.01 → 3.9
I confirm that this is an enhancement request. :-) I found the following relevant URLs http://www.alvestrand.no/objectid/1.3.6.1.5.5.7.1.3.html http://www.alvestrand.no/objectid/0.4.0.1862.1.1.html http://www.ietf.org/rfc/rfc3039.txt ftp://ftp.rfc-editor.org/in-notes/rfc3739.txt This extension contains one or more OIDs that represent "statements". If the extension is marked critical, then each and every one of the statement OIDs contained in the extension must be understood (and enforced?) by the relying software in order for that software to consider the extension "known". It appears to me that only way NSS could enforce this would be for the NSS-based application to tell NSS which statement OIDs the application understands and honors. This could be done by having the application register OIDs with NSS, or perhaps with an application-supplied callback that NSS calls to ask the application "do you understand the statement implied by this OID?". I think we'd need to add an API by which the application could ask NSS "which statement OIDs are specified by this cert?"
Status: UNCONFIRMED → NEW
Ever confirmed: true
I found this info on http://jce.iaik.tugraz.at/products/01_jce/documentation/javadoc/iaik/x509/extensions/qualified/structures/etsi/QcEuCompliance.html Begin quote ------------------ The QcEuCompliance statement info is associated with a specific statement identifier, derived from: id-etsi-qcs OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) id-qc-profile(1862) 1 } id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 } which corresponds to the OID string "0.4.0.1862.1.1". The Qualified Certificate profile specifies the QcEuCompliance statement info for indicating that the containing certificate has been issued as a Qualified certificate according Annex I and II of the Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, as implemented in the law of the country specified in the issuer field of this certificate. End Quote ----------------- Viktor, can you tell us what that last paragraph really means? So the cert was issued is compliance with some Directive's Annex. So what? What must an application do to comply with this statement?
Yes, of-course. I copied here some pages from the appendix of the ETSI TS 101 862 V1.3.2 This is the complete, and here is included the latest qcStatement about the SSCD. ---- copied pages starts here ---- (source: http://www.etsi.org ) ETSIQCprofile { itu-t(0) identified-organization(4) etsi(0) id-qc-profile(1862) id-mod(0) id-mod-qcprofile- 2(02) } DEFINITIONS EXPLICIT TAGS::= BEGIN -- EXPORTS All -- IMPORTS QC-STATEMENT, qcStatement-1 FROM PKIXqualified93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-qualified-cert-93(11)}; -- statements esi4-qcStatement-1 QC-STATEMENT ::= { IDENTIFIED BY id-etsi-qcs-QcCompliance } -- This statement is a statement by the issuer that this -- certificate is issued as a Qualified Certificate according -- Annex I and II of the Directive 1999/93/EC of the European Parliament -- and of the Council of 13 December 1999 on a Community framework -- for electronic signatures, as implemented in the law of the country -- specified in the issuer field of this certificate. esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED BY id-etsi-qcs-QcLimitValue } -- This statement is a statement by the issuer which impose a -- limitation on the value of transaction for which this certificate -- can be used to the specified amount (MonetaryValue), according to -- the Directive 1999/93/EC of the European Parliament and of the -- Council of 13 December 1999 on a Community framework for -- electronic signatures, as implemented in the law of the country -- specified in the issuer field of this certificate. QcEuLimitValue ::= MonetaryValue MonetaryValue::= SEQUENCE { currency Iso4217CurrencyCode, amount INTEGER, exponent INTEGER} -- value = amount * 10^exponent Iso4217CurrencyCode ::= CHOICE { alphabetic PrintableString (SIZE 3), -- Recommended numeric INTEGER (1..999) } -- Alphabetic or numeric currency code as defined in ISO 4217 -- It is recommended that the Alphabetic form is used esi4-qcStatement-3 QC-STATEMENT ::= { SYNTAX QcEuRetentionPeriod IDENTIFIED BY id-etsi-qcs-QcRetentionPeriod } -- This statement is a statement by which the issuer guarantees -- that for the certificate where this extension appears that the -- information received from the subscriber at the time of -- registration will be archived and can be made available upon -- request beyond the end of the validity period of the certificate -- for the number of years as indicated in this statement. QcEuRetentionPeriod ::= INTEGER esi4-qcStatement-4 QC-STATEMENT ::= { SYNTAX QcSSCD IDENTIFIED BY id-etsi-qcs-QcSSCD } -- This statement is a statement by which the issuer claims -- that for the certificate where this statement appears that -- the private key associated with the public key in the certificate -- is protected according to Annex III of the Directive 1999/93/EC of -- the European Parliament and of the Council of 13 December 1999 on a -- Community framework for electronic signatures. -- object identifiers id-etsi-qcs OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) id-qc-profile(1862) 1 } id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 } id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 } id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 } id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 } -- supported statements SupportedStatements QC-STATEMENT ::= { qcStatement-1 | esi4-qcStatement-1 | esi4-qcStatement-2 | esi4-qcStatement-3 | esi4-qcStatement-4, ...} END ---- copied pages are ending here ---- At first you should know about these directives some more. (copeide from the same source. This was a table, but to put this here, i should modificate a litle bit. lines marked with R is requirments, (Requirement from Annex I in the Directive 1999/93/EC [1]) and after them , lines marked with I are the corresponding solutions (Implementation according to this profile and underlying standards) R) (a) an indication that the certificate is issued as a Qualified Certificate; I) Inclusion of certificate policy defining this property and/or an explicit statement defining this property as defined in clause 5.3. R) (b) the identification of the certification-service-provider and the State in which it is established; I) By information stored in the issuer field as defined in clause 3.1.1 of the IETF Qualified Certificate Profile RFC 3739 [4]. The certificate must clearly indicate the country in which the issuer is established as defined in clause 5.1. R) (c) the name of the signatory or a pseudonym, which shall be identified as such; I) As defined in clause 3.1.2 of the IETF Qualified Certificate Profile RFC 3739 [4]. R) (d) provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for which the certificate is intended; I) As defined in clauses 3.1.2 and 3.2.1 of the IETF Qualified Certificate Profile RFC 3739 [4]. R)(e) signature-verification data which correspond to signature-creation data under the control of the signatory; I) The public key with the associated information listed in annex A. R) (f) an indication of the beginning and end of the period of validity of the certificate; I) The validity period according to ITU-T Recommendation X.509 [2] and RFC 3280 [3]. R) (g) the identity code of the certificate; I) The serial number of the certificate according to ITU-T Recommendation X.509 [2] and RFC 3280 [3]. R) (h) the advanced electronic signature of the certificationservice- provider issuing it; I) The digital signature of the issuer according to ITU-T Recommendation X.509 [2] and RFC 3280 [3]. R)(i) limitations on the scope of use of the certificate, if applicable; and I) Provided by information in the certificate Policies extension, the Key Usage Extension and the Extended Key Usage Extension according to ITU-T Recommendation X.509 [2] and RFC 3280 [3]. R)(j) limits on the value of transactions for which the certificate can be used, if applicable. I) According to clause 5.2.2 of the present document. And now the Annex II, in the same structure R = Requirement from Annex II in the Directive 1999/93/EC [1] S = Supporting mechanisms R) Requirement b) includes requirement on a secure and immediate revocation service. S) The certificate extensions CRL distribution point and authority information access according to RFC 3280 [3] may contain information used to find and identify these services. R) Requirement i) includes requirement on retention of relevant information for an appropriate period of time. S) Clause 5.2.3 defines a statement that can be used to communicate the retention period to relying parties. R) Requirement k) states that relevant part of the terms and conditions regarding the use of the certificate shall be made available on request to third-parties relying on the certificate. S) A certificate policy identified in the certificate policies extension may contain a qualifier of the type "CPSuri", according to RFC 3280 [3], pointing to the location where such information can be obtained. -------- end of copies ---- Lets talk about things, without copying laws here. I have talked about the solutions with our ISO professional, and we have checked the using conditions of this parameter in a working applications. (Windows based application, using the Windows certificate store) One possible solution for this is the following: 1) At first, the Mozilla must understand this extension, so if somebody checks it in the certificate store, with the Mozilla, it should list in human readable text the statements and the limit value too (which are presented in the certificate) (Otherwise, I think, ther is a some extension, which are not converted to the readable form in the certificate manager, like Netscape Comment, etc.) 2) When somebody imports a certificate into the cert.store, a pop-up window with the statements and value and an "I have read them" or simmilar button are one part of solution. 3) There should be an API where the application can get the extensions from the NSS. We think, this is enough, because, you can not verify if an application tell to you, "Yes, I can understand" that it is truth. An application can lie. (We have checked the Windows application I mentioned previously, but after you give the parameters for it, you can't verify, what he does.) Checking the softwar3e (is that software using the qcstatement fields?) should be made by the official assigned quality certificate company. These certificate companies should assinged by the goverment, and by the law. For summary we think, only the API with the possibility to request the extensions is enough for the applications, the other changinsg needed are only the recognition of an extension, and transformation to human readable text. Any other idea?
I forgot one small comment: Because the statements are contstant strings, depending on the extension, maybe it is good, if they are printed on the screen and readdable from the certificate store (details), if they are transalted to native languages in the localised versions. Of-course I can do the hungarian transaltions of it.
Thanks for copying the relevant annexes here. Most of those lettered requirements merely restate generic certificate requirements that are required for all certs, and not only for certs with qcStatements, e.g. cert must have a subject name, in issuer name, and a serial number. Requirements b, c, and d also require (by reference to RFC 3739) that the cert's issuer and subject names contain "an appropriate subset" of the standard DN attributes. Of those requirements, the only enforceable ones are (a) that the name must contain at least one of commonName, givenName, and pseudonym, and (b) that use of psuedonym is mutually exclusive with use of givenName and surName. (if you use pseudonym, the others are forbidden). I'd say that an application need not do anything specific (beyond recognizing the OIDs) to "recognize" or enforce the following statements : id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 } id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 } id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 } because those statements are unilateral statements by the issuer about the issuer's own obligations. But this statement id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 } seems to burden the relying party to understand and perhaps enforce the QcEuLimitValue which is a MonetaryValue > R)(j) limits on the value of transactions for which the certificate > can be used, if applicable. > I) According to clause 5.2.2 of the present document. Viktor, What does clause 5.2.2 say? IMO, the issue of unrecognized critical extensions is not primarily of importance at import time, but rather at cert chain validation time. That is, the time at which NSS might ask the application if it understands the extension would not be at import time, but at validation time. For extensions that require application participation, the simple cert import utilities, such as certutil and pk12util, will certainly NOT understand them. And a cert DB might be used (at different times) by apps that do understand these OIDs, and by apps that do not. So, I would say that the app's understanding of the qcStatement OIDs is not necessarily a requirement for import into the DB, but is a requirement for cert chain validity processing. I'm working on a proposal to extend the definition of NSS's understanding of an extension's recognition, so that NSS can enforce different policies at import time than at chain validation time. Bob, what do you think about all this?
In general I think it's OK, though I'm a bit worried about maintaining it. Are you thinking that we would not enforce policy, critical extensions, etc, or that we would have a separate list of critical extensions which say "We understand this extension well enough to import it, but not well enough to use it". The next question is what do we do when a certificate with id-etsi-qcs-QcLimitValue is used in other contexts, such as email, or SSL authentication. In these cases, there is no 'monetary value' that the browser/mail client knows about. Perhaps the mail client could throw up chrome that says 'signature valid only for requests less an $X'. I don't know about SSL. Do we need a way for the server to say "My application is OK with this extention" either because it's not dealing with money, or it will parse the extension itself? Or do we not need to worry about the SSL part because there is no way to prove to a their party that some one was authenticated simply on the basis of there SSL authentication. Summary -- I think import is OK, I think SSL client auth is probably too, but I would like a second opinion. We need a way for clients to tell us what additional extensions they understand. bob
I discovered that the only place where NSS ever sets the error SEC_ERROR_UNKNOWN_CRITICAL_EXTENSION is in CERT_DecodeDERCertificate(), /security/nss/lib/certdb/certdb.c, line 863 which is called from CERT_NewTempCertificate, among others. That tells me that a) today we can't do ANYTHING with certs with unknown critical extensions, except print them with pp. and b) we don't have code that checks certs for unknown critical extensions in the cert chain validation code. The assumption is that if we have a pointer to a CERTCertificate, it must be a cert with no known critical extensions. Removing the check in CERT_DecodeDERCerticate, and adding checks in many other places where the check is now implicit in the non-null cert pointer seems dangerous. I wonder how many regressions would creep in, and how long it would take to root them all out. Today our secoid table requires each known OID to have a "supportedExtension" value, which is an enum with these 3 values: 411 typedef enum { 412 INVALID_CERT_EXTENSION = 0, 413 UNSUPPORTED_CERT_EXTENSION = 1, 414 SUPPORTED_CERT_EXTENSION = 2 415 } SECSupportExtenTag; I'm thinking we might add two more values: CONDITIONALLY_SUPPORTED_CERT_EXTENSION = 3 which means, "we recognize it enough to import it and parse it, but we don't know how to enforce it - that's the application's job." and SUPPORTED_SUBTYPE_CERT_EXTENSION = 4 which says "This OID is known by the local application. If it appears in a conditionally supported cert extension, it's not unknown." We already have a means for an application to dynamically register additional OIDs in the oid table. I would propose that applications would use this means to register OIDs for "qualified statements" that they understand. The present function SECOID_KnownCertExtenOID() would be changed to return true for either SUPPORTED_CERT_EXTENSION or CONDITIONALLY_SUPPORTED_CERT_EXTENSION, so that this type would pass muster enough to be imported. Cert chain validation would have an additional step, which finds any critical extensions of type CONDITIONALLY_SUPPORTED_CERT_EXTENSION, and then checks each of the OIDs within it to see if they are known as SUPPORTED_SUBTYPE_CERT_EXTENSION. (This particular aspect of this proposal needs more polish.) Thoughts?
> Viktor, What does clause 5.2.2 say? at first, i copy it here, then later I am going to reply to the other things. --- copy start --- 5.2.2 Statement regarding limits on the value of transactions The limits on the value of transactions, for which the certificate can be used, if applicable, may be indicated using the statement defined in this clause. The codes are defined in ISO 4217 [9]. This optional statement contains: • an identifier of this statement (represented by an OID); • a monetary value expressing the limit on the value of transactions. esi4-qcStatement-2 QC-STATEMENT ::= { SYNTAX QcEuLimitValue IDENTIFIED BY id-etsi-qcs-QcLimitValue } -- This statement is a statement by the issuer which impose a -- limitation on the value of transaction for which this certificate -- can be used to the specified amount (MonetaryValue), according to -- the Directive 1999/93/EC of the European Parliament and of the -- Council of 13 December 1999 on a Community framework for -- electronic signatures, as implemented in the law of the country -- specified in the issuer field of this certificate. QcEuLimitValue ::= MonetaryValue MonetaryValue::= SEQUENCE { currency Iso4217CurrencyCode, amount INTEGER, exponent INTEGER} -- value = amount * 10^exponent Iso4217CurrencyCode ::= CHOICE { alphabetic PrintableString (SIZE 3), -- Recommended numeric INTEGER (1..999) } -- Alphabetic or numeric currency code as defined in ISO 4217 -- It is recommended that the Alphabetic form is used id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 } --- copy end ---
(In reply to comment #8) > In general I think it's OK, though I'm a bit worried about maintaining it. > Are you thinking that we would not enforce policy, critical extensions, etc, or > that we would have a separate list of critical extensions which say "We > understand this extension well enough to import it, but not well enough to use it". I understand your feelings. You can enforce it, to an application, to get this property, but you can't control, what the application relatively does with the statements and the values. > The next question is what do we do when a certificate with > id-etsi-qcs-QcLimitValue is used in other contexts, such as email, or SSL > authentication. In these cases, there is no 'monetary value' that the > browser/mail client knows about. Perhaps the mail client could throw up chrome > that says 'signature valid only for requests less an $X'. I don't know about > SSL. Do we need a way for the server to say "My application is OK with this > extention" either because it's not dealing with money, or it will parse the > extension itself? Or do we not need to worry about the SSL part because there is > no way to prove to a their party that some one was authenticated simply on the > basis of there SSL authentication. > > Summary -- I think import is OK, I think SSL client auth is probably too, but I > would like a second opinion. We need a way for clients to tell us what > additional extensions they understand. Yes, you found the problem of the limitvalue part of the statement. How can somebody give a business value to a mail? Otherwise, this limit is the limit of the liability insurance of the CA. So, you can make with a certificate a higher transaction, but if you have some loss, and the CA was liable for your loss, the liability insurance pays maximum the value included in the limit. There are only a few possible situation, where you can give this value automaticaly: e-banking (like netbanks), e-purchasing (like buy someting on ebay), etc... But most of the situations doesn't have any concrete business value, you can only estimate them for yourself. Viktor
I like the proposal, it covers all the basises except how we deal with the case where NSS has already registered the OID as INVALID_CERT_EXTENSION,UNSUPPORTED_CERT_EXTENSION, or CONDITIONALLY_SUPPORTED_CERT_EXTENSION. Since the OID is already defined, adding it to the table won't change the existing definition. Our verification code will have to look up the OID only in the extended hash list to see if SUPPORTED_SUBTYPE_CERT_EXTENSION is set in these cases. (Maybe we only need to look them up if CONDITIONALLY_SUPPORTED_CERT_EXTENSION is set?). bob
I think it could be better to open a separate bug about dynamically adding support for crtifical extensions ? I've been checking recently that code, because I was interested in checking how Mozilla could support the more common Certificate Policy extesion, when it's made critical. The code I've seen (SECOID_FindOID) checks the dynamically added OIDs before the static list, so it would be OK, except that the function to dynamically add new OID (SECOID_AddEntry) is not called anywhere in the code, is not included in the header files, not exported in the dynamic libraries, and does not include an argument to choose the supportedExtension value (and has a blatant bug because it does not even set the supportedExtension value after allocating the new OID from non initialized memory). I would be great (but more difficult) to be able to add a new CONDITIONALLY_SUPPORTED_CERT_EXTENSION by providing with it a call-back to call to handle it. But I'm not certain the number of case where this would be more useful than what Nelson suggest is high. It could be a significant progress to always allow importation of certificates with unknown critical extension, just not use them. What will happen currently if an installed pkcs#11 token provides a cert with an unhandled critical extension ?
(In reply to comment #12) > I like the proposal, it covers all the bases except how we deal with the case > where NSS has already registered the OID Bob, I don't understand this concern. Please elaborate. Perhaps you could give an example that would illustrate. When searching Extension OIDs or subordinate extension OIDs, the search would search both the dynamic and static OID tables, just as it does now, IINM. Note that NSS *already* allows applications to dynamically add OIDs marked with SUPPORTED_CERT_EXTENSION, thereby enabling new critical extensions whose syntax is unknown to NSS, IINM. This proposal does not change that. Maybe my proposal wasn't clear, so let me embellish it here. I propose to add these new OIDs to NSS's built-in OID table: OID.1.3.6.1.5.5.7.1.3 (identifies a "qualified statement" extension) with supportedExtension value CONDITIONALLY_SUPPORTED_CERT_EXTENSION. id-etsi-qcs-QcCompliance OBJECT IDENTIFIER ::= { id-etsi-qcs 1 } id-etsi-qcs-QcRetentionPeriod OBJECT IDENTIFIER ::= { id-etsi-qcs 3 } id-etsi-qcs-QcSSCD OBJECT IDENTIFIER ::= { id-etsi-qcs 4 } all with supportedExtension value SUPPORTED_SUBTYPE_CERT_EXTENSION because I believe those 3 "statements" require NO processing by the relying party. These are supported subordinate OIDs of the Qualified Statement extension. (Maybe _SUBTYPE_ is the wrong word there. Maybe that should be SUPPORTED_STATEMENT_CERT_EXTENSION or SUPPORTED_CERT_EXTENSION_STATEMENT. I was trying to have all these manifest constants end with _CERT_EXTENSION.) Applications could dynamically register additional statement OIDs for other statements that they are prepared to handle, such as id-etsi-qcs-QcLimitValue OBJECT IDENTIFIER ::= { id-etsi-qcs 2 } with supportedExtension value SUPPORTED_SUBTYPE_CERT_EXTENSION. I do not believe that an application would ever find that a new statement OID would conflict with an existing extension OID, because I believe that no OID does (or ever will) serve the dual purpose of identifying an extension and also identifying something within an extension (such as a "statement"). Notice that I did not propose to define an "UNSUPPORTED_SUBTYPE_CERT_EXTENSION". A subordinate extension OID is either registered with SUPPORTED_SUBTYPE_CERT_EXTENSION or is not registered. That avoids the type of collision that I think you described. In this proposal, when NSS is doing the full check for unknown critical extensions, it will look at all extensions. For each one that is marked critical, it will pass the test if either (a) that extension OID is marked SUPPORTED_CERT_EXTENSION, or (b) it is marked CONDITIONALLY_SUPPORTED_CERT_EXTENSION *and* all of the subordinate OIDs are known and marked SUPPORTED_SUBTYPE_CERT_EXTENSION. That "full check for unknown critical extensions" might occur elsewhere than when the cert is being decoded (as it presently does), such as at cert chain validation time. A lesser check might be done at cert import/decode time. If you still think there is a problem with already-registered OIDs, please explain it. (In reply to comment #13) Jean-Marc, I suspect you're looking at some old NSS sources. In the NSS 3.10 sources, (the trunk of NSS) SECOID_AddEntry is defined in headers, is exported from the shared libs, and is used by NSS command line tools. Look in nss/cmd/lib/moreoids.c to see it in use. It copies the entire SECOidData struct passed by the caller, so no part is left uninitialized.
OK, yes, I did misunderstand your proposal. I thought you wanted Conditionally supported to mean "import is ok but don't validate". I missed that fact that the other OID's are suboids of a single extension. In that case we don't have a problem. With the proposal. bob
What happens in IE/Opera? Do IE/Opera ignore there is a criticial extension it doesn't understand and process it anyway? Or do IE/Opera inform the user as desired? Are there proposals how a user agent should inform the user about the limitations involved with a certificate used in the current security session? I think we would need to use both prompts and additional space on the screen. The prompt must appear as soon as the site is entered, because the URL accessing the first secure page could already be triggering a transaction. Sounds to me like end users will not be very happy dealing with such sites, because if we implemented it that way, they would have to confirm those prompts often. We could of course add another status bar area that permanently displays a short text message, clickable for more details, explaining the limitation of the current session. But as I said, the URL that led to the current display could already have triggered a transaction, and therefore IMHO the status bar area is not sufficient to warn the user. However, for subsequent actions within the same context, we could assume the user is aware of the display, and would not have to repeat the prompts. And finally, the user must be allowed to cancel the request BEFORE it happens. Unfortunately, as described in bug 62178, the Mozilla applications are currently unable to cancel a transition from a non-secure to a secure page. That is, a form action, starting on a non-secure page, requesting a SSL-secured page using such a limitation certificate, where the initial request is causing the transaction to happen, would allow us to inform the user with a message. However, as long as bug 62178 isn't fixed, the user will not be able to cancel the transaction from happening. Just some first thoughts. Probably we should discuss the UI issues in separate bugs filed on the respective application.
(In reply to comment #16) > What happens in IE/Opera? > Do IE/Opera ignore there is a criticial extension it doesn't understand and > process it anyway? > Or do IE/Opera inform the user as desired? I have imported them into IE and Opera too... Neither the IE neither the opera did anything when I imported them. I checked them into the view, and it seems, they are not recognised this property: Opera 7.54u1 (...) Extensions X509v3 Basic Constraints (Critical): CA:TRUE, pathlen:4 X509v3 Key Usage (Critical): Certificate Sign, CRL Sign qcStatements (Critical): 00......F.. IE 6 (...) If i check them, i can find the exclamation mark, which means critical, and the OID of the extension. So it seems, the IE can display the extension OID, but don't know and use this extension.
I think you just demonstrated that IE ignores unknown critical extensions. That's probably worthy of a CERT security alert. Since you found it, you deserve the credit. Please file a request-for-enhancement against FireFox and also one against Thunderbird about the need for UI for this cert feature. An NSS bug is definitely NOT the place for the UI aspect of the discussion. I'd suggest filing the bug against PSM, but I know it would be ignored there. I don't think that "enforcing" this feature necessitates showing a dialog on which the user must click OK. for https, it's probably sufficient to show the limit in the browser's chrome somewhere.
(In reply to comment #16) > Are there proposals how a user agent should inform the user about the > limitations involved with a certificate used in the current security session? Yes, I have a proposal. I read trough the bug that you mentioned, but i think, it is not the way. 1) Imorting the root certificate should be allowed, and the using too. 2) When a user imports a QA level user certificate, he/she must be asked about the accept of statement. (If he/she have a this type of certificate, he/she had to sign it before on paper.) So i think it is enough if you give a popup, and two button. One of the is 'I agree, import please...' the other is 'I don't agree, don't import'. 3) Maybe there should be an API, which is accessible from an application, and if an application can read the presence of extension.
(In reply to comment #18) > I think you just demonstrated that IE ignores unknown critical extensions. > That's probably worthy of a CERT security alert. Since you found it, > you deserve the credit. Sorry, but i dont know. What should I do?
This is not only an issue for root CA certs, and it is not only an issue at the time that root CA certs are "imported". In fact it may not be an issue at the time of "import" at all. It is an issue for all certs, including SSL server certs. And it is an issue for certs that are never "imported" by the user, including ones that come bundled with the software. Given that not all certs have these constraints, the user needs to be aware of which servers do, and which do not, have these constraints, as he is visiting them. And the user must be made aware, regardless of whether the constaint is in a CA cert or a server cert or an email cert.
(In reply to comment #21) > This is not only an issue for root CA certs, and it is not only an issue > at the time that root CA certs are "imported". In fact it may not be > an issue at the time of "import" at all. Ok, i will submit another request for the mentioneds, but what should I do with the IE?
Blocks: 281811
Blocks: 281814
No longer blocks: 274723
QA Contact: bishakhabanerjee → jason.m.reid
Maybe closable. Read my comments here: https://bugzilla.mozilla.org/show_bug.cgi?id=281811
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Summary: Cannot import root certificate, where the qcStatement set to critical. → add support for qcStatement extensions
even if signature validation for qc statements unfortunately isn't a priority, being able to use such a key pair through a pkcs11 device to sign would be great: bug 343717
Priority: -- → P4
Swiss CAs are currently mandated by law to issue qualified certificates only with the purpose "non-repudiation". One group of people concludes from this that "you are not allowed to use qualified certificates for emails, only for documents such as pdfs". My preference would be a) validate signature if correct and have a pop-up/warning that the cert purpose was only "non-repudiation" and not "signing" b) mark the signature as invalid, but be in the explanation text clear that all was fine, except for the purpose.
> Swiss CAs are currently mandated by law to issue qualified certificates only > with the purpose "non-repudiation". One group of people concludes from this > that "you are not allowed to use qualified certificates for emails, only for > documents such as pdfs". My preference would be > a) validate signature if correct and have a pop-up/warning that the cert > purpose was only "non-repudiation" and not "signing" > b) mark the signature as invalid, but be in the explanation text clear that all > was fine, except for the purpose. All of the options seems to be false. The Digital Signature bit should use only for short time authentication, like the client authentication with certificate. Signing with a certificate which has the Non-Repudation bit, is the classic digital signature by the law in Hungary. The regarding RFC (about qualified certificate) says, you should only put the NonRep bit into a qualified certificate. If you will handle well them, you should do the following. Cert has only NonRep -valid for signing any document, mails too Cert has only DigSig -valid for only authentcation purpose Cert has NonRep and DigSig too (not recommended combination by RFCs and ETSIs) -valid for signing and authenticating The reason, why these were separated, that when you do some certificate authentication, the server drops for you some random data, and you sign it with your keys. It is possible to hack a server to drop not a random data, but a contract, and you will sign it when you will authenticate yourself.
Viktor, Thanks for the clarification - this makes sense to me. Just FYI - as of this month, the Swiss Authorities allow accredited CAs to issue qualified certificates that a) also have the signing purpose b) no longer have the qc statement as critical see http://www.bakom.admin.ch/org/grundlagen/00563/00564/00682/index.html?lang=de (German only :( )
There are clean reasons, why you don't include together the KeyEnc, DigSig, NonRep bits. I think it was a bad decision.
This bug is now somewhat old. I'd like to ask some questions about the current situation. At the present time: - is Netlock still issuing certs with critical qcStatement extensions? - is Netlock still issuing SSL server certs with qcStatemenr extensions? A representative of a (different?) Hungarian CA claims that their SSL server certs do not have qcStatement extensions and that the qcStatement extensions are not marked critical in those certs that bear them. So, I wonder if things have changed in Hungary since this bug was filed.
Dear Nelson, Answering your questions: -yes we issue certificates with qcStatement, but they are not set to critical. -no, we never issue SSL certificates with qcStatement. The bug was reported when the qcStatement was a fresh thing, i want to revise all my reported bugs. The qcStatement is much more a "licence" than a real extension. :) I think, this bug should be closed.
It would be useful to display the values of the QC extensions on the certificate details as more and more qualified certificates are being issued in different EU countries (e.g., citizen's cards in Portugal and Spain).
adding kaspar to cc list who often worked on the code to display cert attributes
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.