Re: DigiCert OCSP services returns 1 byte

On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek wrote: > I also don’t think it’s helpful to try to redefine long-standing and > well-understood terminology like what it means to issue a certificate. In > fact, I just checked, and using a definition like “reserving a serial > number” causes many of

RE: DigiCert OCSP services returns 1 byte

I think “IETF does not define policy” is about as true as “individuals represent themselves at IETF.” But that’s a longer rathole. I also don’t think it’s helpful to try to redefine long-standing and well-understood terminology like what it means to issue a certificate. In fact, I just che

Re: DigiCert OCSP services returns 1 byte

On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think that's fine as Mozilla and/or the CABF can and should override > RFCs when it makes sense to do so, but I think it would also be helpful in > the long term to fix the dis

RE: DigiCert OCSP services returns 1 byte

> Thanks Wayne. You're right. > > (I read the "SHOULD NOT" requirement, forgot it had been superseded, and > didn't read further. I wonder if it would be reasonable to remove the > superseded requirement from the BRs now, given that it was superseded over > 6 years ago?) Removing out of date req

RE: DigiCert OCSP services returns 1 byte

Sorry for being unclear. If the IETF goes the direction of "pre-certificates are not certificates", then we find ourselves in a world where the RFCs say that they should not get OCSP services, but Mozilla policy (and potentially the BRs) says that they should. I think that's fine as Mozilla and

Re: OCSP responder support for SHA256 issuer identifier info

Thanks for raising this! There some some slight past discussion in the CA/B Forum on this - https://cabforum.org/pipermail/public/2013-November/002440.html - as well as a little during the SHA-1 deprecation discussions ( https://cabforum.org/pipermail/public/2016-November/008979.html ) and crypto

Re: Apple: Precertificates without corresponding certificates return OCSP value of "unknown"

Thank you for the notification. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1582519 to track this issue. - Wayne On Fri, Sep 13, 2019 at 4:24 PM Apple CA via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We’ve been following the discussions regarding how O

Re: DigiCert OCSP services returns 1 byte

I have gone ahead and added a section titled "Precertificates" [1] to the Required Practices wiki page. I have also updated a policy issue [2] suggesting that this be moved into the Root Store policy, and added a new issue [3] suggesting that we clarify the acceptable use of the "unknown" OCSP res

Re: OCSP responder support for SHA256 issuer identifier info

I think that, if the responder is capable of understanding another hash (e.g. SHA-256), and has support for that built into its backend database, returning the CertID with those supported hashes is fine and good. IMO, there should be no prohibition on supporting alternative hash algorithms. But

Re: OCSP responder support for SHA256 issuer identifier info

I am looking at this from an interoperability perspective and not security. If a client is requesting a SHA256 hash for the issuerNameHash and issuerKeyHash I don’t think the OCSP responder should be prohibited from returning a response containing issuerNameHash and issuerKeyHash using SHA256. I

Re: OCSP responder support for SHA256 issuer identifier info

I'm not aware of any requirement that demands that OCSP responders support SHA-256 for CertID.hashAlgorithm or of any requirement that forbids this. Therefore, I think 1, 2 and 4 are all acceptable responses to an OCSP request whose CertID.hashAlgorithm is SHA-256. SHA-1 is the defacto require