István Zsolt BERTA wrote, On 2008-10-06 06:54: > 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 > "
> 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. A trusted responder is a responder CHOSEN BY THE RELYING PARTY. The model is that the user chooses a single OCSP responder to which all of his OCSP requests will be sent. Those OCSP requests may include information about the OCSP URI that was present in the certificate under test, so that the trusted responder may contact the issuer's responder for more information, but the final response received by the requester MUST be signed by the relying party's trusted responder. This model is used in some corporations where the trusted responder sits on a gateway/firewall system where it can be accessed by the users behind the firewall, and will have access to the issuers' OCSP responders on the internet. One reason to do this is to provide caching of OCSP responses. Mozilla products have the configuration option (a preference) by which the user can choose a single OCSP responder to which ALL of that user's OCSP requests will be sent. There is no particular relationship required between that responder and any issuer. The user must have a certificate for that responder and must select it as being THE SOLE cert that the client will trust for those OCSP responses. > Based on the above, we consider our solution RFC 2560 conformant. Now, if your OCSP responder is able to act as such a universal trusted OCSP responder, and its cert is available for your customers to download and trust for OCSP responses, then I would agree that *that responder* could be said to be RFC conformant. But if all your certs give AIA extensions that point to that responder, so that all relying party software for users who have not chosen to trust that responder as their delegated responder will still try to access that responder, then that's a problem, because those other users will get a response that they will be unable to prove comes from the issuer of the cert under test. I would not recommend that all Mozilla users should use a Hungarian responder as their delegated OCSP responder. It may be fine for Hungarian users (and any others who wish) to do so, but if only the users who choose to do so (and to pay for the privilege) will have OCSP service for the Hungarian certs, then I think the roots of the issuers of those certs should only be trusted by the users who choose to do so. In other words, the same users who choose to configure their browsers to trust a Hungarian OCSP responder as their delegated OCSP responder could (and should, IMO) also install and trust the associated root CA cert for the certs that will cite that responder for OCSP requests. > (We know of other similar solutions, e.g. openvalidation.org works > exactly this way.) Users choose to trust that organization's responder as their universal delegated responder, IINM, irrespective of the OCSP URI in the cert under test. > 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. According to Indiana legislation, at one time, the value of pi was 3.2. :) My point is that it is unfortunate if Hungarian law/regulation prohibits Hungarian CAs from using OCSP in a way that is useful for the general populace of the Internet, but the rest of the internet is not likely to change its software to accommodate those unfortunate regulations. > 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.) Well, of course, ALL revocation information is issued AFTER the time of signing of the cert. No CA issues already-revoked certs. > 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. The question is: are the certs that rely on that responder useful to the general public without it? > 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. I opine that Mozilla should require that. Specifically that mozilla should require that any OCSP URI in a server cert MUST work for Mozilla users everywhere. > Unrecognized extensions: > ------------------------ > 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. 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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
