Kaspar Brand wrote, On 2008-06-29 10:10: > Michael Ströder wrote: >> Not that I'm endorsing setting cert/CRL download up with HTTP redirects >> but I cannot derive from the text snippet above that it's forbidden or >> explicitly not recommended. > > In my interpretation of RFC 5280, the statement "When the HTTP or FTP > URI scheme is used, the URI MUST point to a single DER encoded CRL" > implicitly disallows redirects - the URI would not point to a CRL then, > but to another URI instead.
This issue came up in the CABForum recently. As I recall, Opera announced that their browser does not honor redirects of http fetches for certain things, and IIRC, CRLs was one of them. It came to light that at least one major CA routinely redirects CRL requests. I would say that the majority of those members who expressed an opinion on it said that they believed that redirects were valid and should be supported. >> I'm rather scared of implementations not capable to follow HTTP redirects. That seems like an odd reaction. >>From a short look at the HTTP client built into libpkix, I don't think > that it's willing to handle anything other than "200 OK" > (http://lxr.mozilla.org/seamonkey/source/security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_httpdefaultclient.c#244): > >> 244 if (client->responseCode != 200) { >> 245 client->connectStatus = HTTP_ERROR; >> 246 goto cleanup; Yeah, there's a bug filed about that, IIRC. > (Things are different if Necko is used, of course.) Indeed. That's why I wrote that it depends on the http engine being used. Applications can use one of NSS's built in engines, or supply their own. NSS's built in http engine doesn't handle any kind of proxies, which is the major reason that FF uses Necko's engine. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
