Last Comment Bug 277797 - add support for qcStatement extensions
: add support for qcStatement extensions
Status: NEW
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.9
: x86 Windows XP
: P4 enhancement with 3 votes (vote)
: ---
Assigned To: nobody
:
:
Mentors:
Depends on:
Blocks: 279728 281811 281814
  Show dependency treegraph
 
Reported: 2005-01-10 09:42 PST by Varga Viktor
Modified: 2009-03-11 07:57 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Varga Viktor 2005-01-10 09:42:31 PST
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-----
Comment 1 Varga Viktor 2005-01-13 07:15:57 PST
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.
Comment 2 Nelson Bolyard (seldom reads bugmail) 2005-01-19 22:10:03 PST
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.  
Comment 3 Nelson Bolyard (seldom reads bugmail) 2005-01-19 23:03:40 PST
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?"
Comment 4 Nelson Bolyard (seldom reads bugmail) 2005-01-19 23:15:46 PST
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?
Comment 5 Varga Viktor 2005-01-25 07:13:13 PST
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?

Comment 6 Varga Viktor 2005-01-25 07:20:19 PST
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.

Comment 7 Nelson Bolyard (seldom reads bugmail) 2005-01-25 10:03:19 PST
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?
Comment 8 Robert Relyea 2005-01-25 12:28:01 PST
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
Comment 9 Nelson Bolyard (seldom reads bugmail) 2005-01-25 21:02:28 PST
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?
Comment 10 Varga Viktor 2005-01-26 01:59:10 PST
> 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 ---
Comment 11 Varga Viktor 2005-01-26 02:28:52 PST
(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


Comment 12 Robert Relyea 2005-01-26 08:30:23 PST
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
Comment 13 Jean-Marc Desperrier 2005-01-26 10:06:30 PST
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 ?
Comment 14 Nelson Bolyard (seldom reads bugmail) 2005-01-26 19:19:52 PST
(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.  
Comment 15 Robert Relyea 2005-01-27 09:19:12 PST
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
Comment 16 Kai Engert (:kaie) 2005-02-03 11:11:12 PST
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.
Comment 17 Varga Viktor 2005-02-04 00:51:43 PST
(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.
Comment 18 Nelson Bolyard (seldom reads bugmail) 2005-02-04 01:11:02 PST
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.
Comment 19 Varga Viktor 2005-02-04 01:28:16 PST
(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.
Comment 20 Varga Viktor 2005-02-04 05:19:54 PST
(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?
Comment 21 Nelson Bolyard (seldom reads bugmail) 2005-02-04 09:07:31 PST
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.  
Comment 22 Varga Viktor 2005-02-07 01:33:27 PST
(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?
Comment 23 Varga Viktor 2005-10-26 11:26:20 PDT
Maybe closable.

Read my comments here:

https://bugzilla.mozilla.org/show_bug.cgi?id=281811
Comment 24 Ralf Hauser 2006-07-06 00:11:16 PDT
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
Comment 25 Ralf Hauser 2006-11-24 03:53:50 PST
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.
Comment 26 Varga Viktor 2006-11-24 04:06:46 PST
> 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.




 

Comment 27 Ralf Hauser 2006-12-05 22:16:16 PST
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  :( )
Comment 28 Varga Viktor 2007-04-03 09:49:24 PDT
There are clean reasons, why you don't include together the KeyEnc, DigSig, NonRep bits. I think it was a bad decision.
Comment 29 Nelson Bolyard (seldom reads bugmail) 2008-10-06 10:00:31 PDT
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.
Comment 30 Varga Viktor 2008-10-06 10:32:31 PDT
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.
Comment 31 Nuno Ponte 2008-11-12 11:10:04 PST
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).
Comment 32 Kai Engert (:kaie) 2009-03-11 00:41:39 PDT
adding kaspar to cc list who often worked on the code to display cert attributes

Note You need to log in before you can comment on or make changes to this bug.