Dear All, Let me reflect to some of the above points.
First of all, our public website is www.e-szigno.hu. The webpage at https://srv.e-szigno.hu:4444/cgi-bin/editugyvedcsv.cgi is a restricted page, it requires a client-side SSL certificate (with certain values in the subject DN), so you should not be able to access it. I do not know of any (useful) tool capable of translating from Hungarian to English. Please let me know if you find one. OCSP: ----- According to section 2 of RFC 2560, there are three ways to operate an OCSP responder: " All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who issued the certificate in question -- a Trusted Responder whose public key is trusted by the requester -- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA " Later, in section 4.2.2.2 Authorized Responders, RFC 2560 gives more requirements on using the third option, CA designated or authorized responders. We do not use this third option. We support the second option (Trusted Responder), where the requester explicitly trusts the OCSP responder. (In our case the link of trust is established by our CPS stating the the separate root can be trusted for signing relevant OCSP responses.) I do not know of any statement in RFC 2560 that requires the responder to be under the same root. Based on the above, we consider our solution RFC 2560 conformant. (We know of other similar solutions, e.g. openvalidation.org works exactly this way.) 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: * signing qualified end-user certificates and * signing CRLs. As neither 'signing OCSP responses', nor 'singing OCSP responder certificates' is listed here, we were not allowed to support options 1 and 3 marked in RFC 2560, so only option 2 remained. Our OCSP is used by our own customers for creating so-called 'archive signatures' e.g. according to ETSI TS 101 903. (An archive signature is timestamped and the necessary revocation information is also 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.) We understand that our OCSP is not useful for the general public, so we did not wish to include our OCSP root (and support for our OCSP) in Mozilla. If you consider that the OCSP URL in the AIA field poses a problem, we can modify the profile of the SSL server certifictes so the AIA field will not be included. Unrecognized extensions: ------------------------ Our regulations require us to comply with European ETSI specifications. Qualified certificates are one of the key concepts of European PKI regulations and ETSI TS 101 862 defines the QCStatement extension for marking a certificate to be qualified. According to ETSI TS 101 862 this extension is mandatory. This is not a Microsec-specific problem, it affects most of the other European CAs who issue qualified certificates. The QCStatement extension is *NOT* critical in our certificates. Webserver and code signing certificates are generally non-qualified, so they are not affected by this issue. Liability: ---------- In our qualified certificates, the liability limit is included in the certificate. The minimum value is ~5400 USD, the maximum value is ~1 million USD. > They do not claim to include this information in non-qualified certs. Our law does not allow us to do so. We can include it in our CPS only. > Apparently the absence of an explicit liability limit should be understood > to mean no liability. In our country this is exactly vice versa. If you do not state any limit, your liability is unlimited. (This is a general and not a CA- specific rule.) In fact, the liability is unlimited anyway as you can limit it per relying party only. If you limit your liability at $1, you may still need to pay $1million for one million relying parties. In case of class 3 non-qualified certificates this limit is ~$500. > Any cert for which the issuer has no liability is a cert for which the > issuer has no incentive to be accurate. If a CA has no liability for > doing so, what stops it for issuing lots of certs for paypal.com? In fact, we agree that a CA should be responsible for certificates it issues. Still, due to various reasons (mostly because other CAs limit their liability to zero too), we need to offer class2 certificates with zero liability too. Fortunately, we issue very few of these. However, we refuse to issue webserver and code signing certificates as class2, and we require them to be at least class3 (where the CP is based on NCP or NCP+ and thus a face-to-face registration is used) where our liability is non-zero. > [1] Fun fact: Within Hungary names are normally given in "Eastern order" > (i.e., like China or Japan) with surname first. In this case I've > transposed to Western order (I think). Sometimes we transpose our names ourselves, so that Western people can figure out which one our first name is. Sometimes we meet people who know that Hungarian names are written "the opposite" way, so they do the transposition again. Conclusion: in case of Hungarians you never know which the first name and which the surname is. :) Bye, István (this is my first name) _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
