Re: OCSP responder support for SHA256 issuer identifier info

2019-09-19 Thread Rob Stradling via dev-security-policy
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

Re: OCSP responder support for SHA256 issuer identifier info

2019-09-19 Thread Neil Dunbar via dev-security-policy
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.

RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
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

Re: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Wayne Thayer via dev-security-policy
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

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

2019-09-19 Thread Wayne Thayer via dev-security-policy
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

RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
> 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

Re: OCSP responder support for SHA256 issuer identifier info

2019-09-19 Thread Ryan Sleevi via dev-security-policy
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: OCSP responder support for SHA256 issuer identifier info

2019-09-19 Thread Curt Spann via dev-security-policy
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.

Re: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Ryan Sleevi via dev-security-policy
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

RE: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Tim Hollebeek via dev-security-policy
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

Re: DigiCert OCSP services returns 1 byte

2019-09-19 Thread Ryan Sleevi via dev-security-policy
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