As I see we all agree on the fact that a 'trusted responder' can exist according to RFC 2560, and it is possible that an OCSP responder certificate is under a separate root. (There are various scenarios for providing OCSP service, it can be provided by a CA directly or by proxy responders, etc. but RFC 2560 does not deal with such issue.)
Thus, I refuse any statement that would claim that our solution is not RFC 2560 conformant. However, I accept that this way it could be very hard for an application to automatically verify that a certain responder can be trusted for answering OCSP requests for a certain certificate. Moreover, our OCSP is currently not open for the general public, so our OCSP service is not useful for Mozilla users. We knew this from the very beginning, this is why we did not even ask for the inclusion of our OCSP root in Mozilla. > The question is: are the certs that rely on that responder useful to > the general public without it? Yes, this is the real question. We say that yes, they are useful, as they can be verified using CRLs. As I read above, it currently does not pose a problem that there is an OCSP URL in the AIA field of the certificate. If you think that this shall become problematic in the future, we can modify the profile of webserver certificates and remove the OCSP URL (as long as the OCSP is not useful for the general public). > > We had good reasons to choose this solution. According to Hungarian > > regulations, a qualified CA is allowed to use its private key for the > > following two purposes only: > You are not allowed to issue intermediate CA certificates then? Are you > issuing directly from the CA root? The CA key used for signing qualified certificates can be used for signing qualified end-user certificates and CRLs. This also means that we cannot issue intermediate CA certificates with that particular key and we cannot issue non-qualified certificates either. We have a root, which does not issue end-user certificates, but issues CA certificates for our own CAs only. These 'productive' CAs can issue either qualified or non-qualified certificates only. This solution was accepted by our authorities. In case of 'productive' CAs issuing qualified certificates the 'trusted responder' remained the only option. > What are the checks performed on code-signing certificates? 1. We verify the existence of the company which requests the code- signing certificate using an online connection to the Hungarian registry of businesses. 2. We verify the existence of the documents (driving license, ID card or passport) of the person who requests the code-signing certificate on behalf of that particular company. We perform this verification using an online connection to the Office of the Central Office for Administrative and Electronic Public Services. http://www.nyilvantarto.hu/kekkh/kozos/index.php?k=nyitolap_en&b=bal_eng 3. Using a face-to-face registration (as the CP is NCP-based) we verify the identity of the person who requested the certificate on behalf of that company. This person has to meet our registration officer and has to present the document (driving license, ID card or passport) that was verified in step 2. 4. We verify that this person has the authority to sign on behalf of the company. We generally request a notarial deed (issued by a public notary) as a proof. > > attached to the signature. Certain signature policies require that the > > revocation information needs to be issued _after_ the time of signing, > > i.e. the point of time marked in the timestamp on the signature.) > Well, of course, ALL revocation information is issued AFTER the time of > signing of the cert. No CA issues already-revoked certs. No, I meant: revocation information issued after the creation of an _electronic_signature_. I was referring to a concept known as 'grace period'. This means for example that if a signature had been created on Wednesday, it should not be accepted based on a CRL issued on Monday (because the certificate of the signatory could have been revoked on Tuesday). This a European concept that appears e.g. in CEN Workshop Agreement CWA 14171, Section 5.3. ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14171-00-2004-May.pdf This concept is specific to electronic signatures, and cannot be applied for e.g. webserver certificates. This concept is also the subject of many debates. > In bug 277797, a representative of a Hungarian CA claims that their > SSL server certs ARE qualified certs. If that is still true > (and it may not be, since that bug is a couple years old), then it > cannot be said that web server certs are generally non-qualified. The EU Directive is about electronic signatures only (and e.g. not about SSL), so the word 'qualified' can be used in the context of electronic signatures only. According to ETSI TS 102 280, Section 5.4.3, only the DigitalSignature and NonRepudiation key usage bits may appear in certificates used for signing. This means, a qualified certificate - a certificate used for signing - cannot be used for SSL. This EU requirement appears in Hungarian legislation too: according to 13. § (4) of the Hungarian act on electronic signatures, a private key used for creating electronic signatures must not be used for any other purpose (e.g. decryption, SSL authentication, etc). This means, a webserver certificate cannot be qualified in Hungary. I used the word 'generally', because other EU member states may implement both the Directive and ETSI specifications differently. Some countries are more, some countries are less strict on this issue. Regulations also change in time. At the time when bug 277797 was submitted, key usage bits in certificates was not a central issue for our authority. A National Communications Authority statement in this field has been published in late 2005, after bug 277797 was submitted only. > Yes, true. As I understand it, it was the intention of the > directive that only human persons be the holders of qualified > certificates. However when the CAs, industry and govt. departments > started working with them, they discovered problems with this > limitation. Different countries approached the problems in > different ways. In some countries, I gather, qualified certs can be > issued outside the strict intent of the directive. Yes, different countries apply such concepts differently. According to the Directive, qualified signatures are equivalent with handwritten ones, so only natural persons were meant to have qualified certificates. However, in certain countries, electronic invoices have to be signed with qualified certificates. This led to the situation where - in some countries - automated mechanisms also create qualified signatures. This is very far away from the original goal. > Istvan, would it be possible to take the position that "signing > CRLs" is equivalent to signing OCSP responses or OCSP certificates? Personally, I agree with you. This requirement in our regulations is the result of a (bad) translation from CWA 14167-01. When we started our services, we were not in the position to question such requirements and argue using common sense. Meanwhile, the situation has changed, new regulations appeared, and relevant statements in ETSI TS 101 456, Section 7.2.5 (Certification authority key usage) have been updated, clarified. Today, we might be in a better position. We shall try to take it into account when we modify our CA hierarchy next time. > How does the Hungarian regulation define the CA ? Generally, it defines a CA as an organization. This particular requirement is not about the organization, it is about a private key - it is stated explicitly. > Unfortunatly, I never had the opportunity to check how this specific > case is handled by NSS :-) I like the idea, but even if NSS handles this correclty, other applications may fail to do so. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
