On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek
> 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
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
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy <
> 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
> 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
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
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
Thank you for the notification. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1582519 to track this issue.
On Fri, Sep 13, 2019 at 4:24 PM Apple CA via dev-security-policy <
> We’ve been following the discussions regarding how
I have gone ahead and added a section titled "Precertificates"  to the
Required Practices wiki page.
I have also updated a policy issue  suggesting that this be moved into
the Root Store policy, and added a new issue  suggesting that we clarify
the acceptable use of the "unknown" OCSP
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.
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'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
Mail list logo