Re: DigiCert OCSP services returns 1 byte

[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 of the issuance requirements in RFC 5280 to be
> non-sensical.
>

It was DigiCert that introduced me to this way of thinking, when they
similarly argued that revocation is the process of marking a serial number
revoked within an internal database, rather than the publication of a CRL
or OCSP response.
https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/7hkz9iJDAQAJ


> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be offered
> for pre-certificates.  It’s merely a question of clarifying the technical
> requirements about how an OCSP service should operate, as those
> requirements currently can be read to not allow OCSP responses for
> non-certificates.
>

I'm still not sure I agree with the conflict, which is the key. In either
event, we're arguably discussing a profile / the operational constraints
specific to a given CA, and not something general with the protocol.
Whether or not a pre-certificate is treated as equivalent issuance is,
ultimately, a policy question.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[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 checked, and using a definition like “reserving a serial number” 
causes many of the issuance requirements in RFC 5280 to be non-sensical.

 

It would be helpful for one of the relevant documents, or another document, or 
even an errata, to clarify that OCSP services can be offered for 
pre-certificates.  It’s merely a question of clarifying the technical 
requirements about how an OCSP service should operate, as those requirements 
currently can be read to not allow OCSP responses for non-certificates.

 

Not sure what reason there would be to oppose such a simple clarification that 
aligns the relevant requirements with the desired policy, especially since it 
is backwards compatible.

 

-Tim

 

From: Ryan Sleevi  
Sent: Thursday, September 19, 2019 2:17 PM
To: Tim Hollebeek 
Cc: Rob Stradling ; Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
; Jeremy Rowley 
Subject: Re: DigiCert OCSP services returns 1 byte

 

 

 

On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy 
mailto: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 discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

 

Isn't the core tenet that the IETF does not define policy? This seems very well 
rooted in policy, as you note.

 

The question does not seem to be about whether or not 
precertificates-are-certificates (and, in a -bis world, they're clearly a 
SignedData-thing-that-isn't), but what constitutes the act of issuance: is it 
signing a thing (whether a TBSCertificate or something other, like a 
precertificate under 6962 or 6962-bis)? Is it reserving the serial number and 
assigning it in the system?

 

In any event, if/when CT is used in other systems, they'll be using different 
CT logs, so they'll really be entirely different ecosystems. It seems that the 
policy management authority (i.e. the equivalent to browsers, in the Web PKI) 
for those ecosystems can provide clarity, and it further emphasizes why a 
single CA certificate should not participate in multiple PMAs, to reduce the 
risk of and avoid conflicts and/or misunderstandings.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[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 discrepancy, especially as CT is likely to be used
> in more certificate ecosystems in the future.


Isn't the core tenet that the IETF does not define policy? This seems very
well rooted in policy, as you note.

The question does not seem to be about whether or not
precertificates-are-certificates (and, in a -bis world, they're clearly a
SignedData-thing-that-isn't), but what constitutes the act of issuance: is
it signing a thing (whether a TBSCertificate or something other, like a
precertificate under 6962 or 6962-bis)? Is it reserving the serial number
and assigning it in the system?

In any event, if/when CT is used in other systems, they'll be using
different CT logs, so they'll really be entirely different ecosystems. It
seems that the policy management authority (i.e. the equivalent to
browsers, in the Web PKI) for those ecosystems can provide clarity, and it
further emphasizes why a single CA certificate should not participate in
multiple PMAs, to reduce the risk of and avoid conflicts and/or
misunderstandings.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[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 requirements was one of the things I did in my spring 
cleanup branch, but I don't know if I caught this one.  There's some even 
older, more obsolete text in there.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert OCSP services returns 1 byte

[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 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 discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.

Note that this doesn't mean that CT-bis has to state that pre-certificates are 
certificates, but it (or something later, or another draft ...) should at 
mention that OCSP responses for pre-certificates are allowed.

-Tim

> -Original Message-
> From: Rob Stradling 
> Sent: Monday, September 16, 2019 5:28 AM
> To: Tim Hollebeek 
> Cc: Jeremy Rowley ; Alex Cohn
> ; mozilla-dev-security-pol...@lists.mozilla.org; Wayne
> Thayer 
> Subject: Re: DigiCert OCSP services returns 1 byte
> 
> On 13/09/2019 19:24, Tim Hollebeek wrote:
> > Yes, but I think this clarifies things in the wrong direction.
> 
> Hi Tim.  I'm not clear what you mean.
> 
> I was talking specifically and only about what IETF could/should do regarding
> this matter.  Which part did you disagree with, and why?
> 
> > -Tim
> >
> >> -Original Message-
> >> From: Rob Stradling 
> >> Sent: Friday, September 13, 2019 4:22 AM
> >> To: Tim Hollebeek ; Jeremy Rowley
> >> ; Alex Cohn 
> >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
> >> 
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> >>> So, this is something that would be helpfully clarified via either
> >>> an IETF draft,
> >>
> >> There's already a 6962-bis draft [1] in IESG Last Call, which (when
> >> we finally complete it!) will obsolete RFC6962.  6962-bis redefines
> >> precertificates so that they're not actually X.509 certificates.
> >> Therefore, I don't think a "clarify RFC6962" draft is necessary.
> >>
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >> A (non-X.509) 6962-bis precertificate contains the serial number that
> >> will appear in the certificate (if or when that certificate is
> >> issued),
> >> so: Should the CA be forbidden, permitted or required to operate
> >> revocation services for that serial number once the 6962-bis
> >> precertificate has been produced but before the certificate has been
> >> issued?  (And is this a technical matter for 6962-bis to address, or
> >> a policy matter that's out of scope for the 6962-bis document?)
> >>
> >>
> >> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
> >>
> >>> or clarifications in the BRs.  There are various things in the OCSP
> >>> RFCs and
> >> even the BRs that can be read as precluding good OCSP responses for
> >> pre- certificates, although the situation is unclear since the
> >> relevant sections are blissfully ignorant of CT, and the correct
> >> behavior here was unfortunately left out of RFC 6962, which should have
> clarified this.
> >>>
> >>> Happy to help draft something.  There are some interesting
> >>> complexities
> >> once you dig deeper.
> >>>
> >>> -Tim
> >>>
>  -Original Message-
>  From: dev-security-policy
>   On Behalf Of Jeremy
>  Rowley via dev-security-policy
>  Sent: Thursday, September 12, 2019 1:46 PM
>  To: Alex Cohn 
>  Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer
>  
>  Subject: RE: DigiCert OCSP services returns 1 byte
> 
>  The language says you have to provide the response for the cert as
>  if it exists, but the reality is that sending a response for the
>  precert is the same as calculating the result for the certificate
>  as if it exists and sending that. They are the same thing because
>  the precert is treated the same as the final cert if the final cert 
>  doesn’t
> exist.
> 
>  I believe the intent is that a CT-naïve OCSP checker would work
>  normally when presented with a precert or a certificate. Afterall,
>  a precert is really just a certificate with a special extension.
> 
>  From: Alex Cohn 
>  Sent: Thursday, September 12, 2019 9:25 AM
>  To: Jeremy Rowley 
>  Cc: Wayne Thayer ; mozilla-dev-security-
>  pol...@lists.mozilla.org
>  Subject: Re: DigiCert OCSP services returns 1 byte
> 
>  On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
>  dev-security-policy
>  mailto:dev-security-
>  pol...@lists.mozilla.org>> wrote:
>  This means, for example, that (i) a CA must provide OCSP services
>  and responses in accordance with the Mozilla policy for all
>  pre-certificates as if corresponding certificate exists and (ii) a
>  CA must be able to revoke a pre- certificate if revocation of the
>  certificate is 

Re: OCSP responder support for SHA256 issuer identifier info

[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 agility discussions (
https://cabforum.org/pipermail/public/2014-September/003921.html ), but
none really nailed it down to the level you have.

Broadly, it suggests the need for a much tighter profile of OCSP, either
within policies or the BRs. Two years ago, I started work on such a thing -
https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large CA
suggested it would take them years to even implement that, and it wouldn't
have covered this!

I can't see #3 being valid, but I can see and understand good arguments for
#1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.

The question about whether #2 is valid is about whether or not a client
should be expected to be able to match the CertID in the
OCSPRequest.requestList to the CertID in the
OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that the
response MUST include a SingleResponse for each certificate in the request,
but may include additional, and so a client encountering a SHA-1 computed
CertID in response to a SHA-256 CertID would have to recompute all the
CertIDs to see if it matched. On the other hand, RFC 5019 2.2.1 states that
"In the case where a responder does not have the ability to respond to an
OCSP response containing an option not supported by the server, it SHOULD
return the most complete response it can."

A different question would be whether said responder, in response to a
SHA-1 request, can and/or should provide a response with both a SHA-1
computed CertID AND a SHA-256 computed CertID. This would improve the
pre-generation performance that Rob was concerned about, and allow both
SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.

However, one concern with the pre-generation approach is that 4.2.2.3
requires that the response MUST include a SingleResponse for each
certificate in the request. RFC 5019 2.1.1 limits clients using that
profile to only include one Request in the OCSPRequest.RequestList (via a
MUST). So should responders be permitted to reject requests that include
multiple? Or should they be required to do online signing? Similar to
extensions.

This suggests we should actually nail down and define what we expect,
perhaps as a clear processing algorithm for how a Responder must respond to
various requests. I suspect that "What we want" is a profile of RFC 5019
that nails down the SHOULD / SHOULD NOT and MAY / MAY NOT behaviours from
5019, as relevant to the Web PKI, and describe a processing algorithm that
can be used to both assess compliance and test implementation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[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 OCSP responders should
> handle Precertificates without corresponding certificates and what the
> appropriate response indicator should be (good, revoked, or unknown).
>
> Based on the recent clarifications at [1], we want to inform the community
> that Apple’s OCSP responders return a status of “unknown” for
> Precertificates without a corresponding certificate. We have identified one
> Precertificate that did not result in a corresponding certificate for which
> our OCSP responders are returning a status of “unknown” (
> https://crt.sh/?id=1368484681).
>
> We’ve updated the OCSP responders to respond “good” for that
> Precertificate and a long-term fix is in progress.
>
> We appreciate the efforts being made to amend the Mozilla Root Store
> Policy to explicitly address matters relating to Certificate Transparency.
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/24Fl9kc-AQAJ
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[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 response.

I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.

- Wayne

[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189

On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer  wrote:

> Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
> and Ryan's:
>
> The current implementation of Certificate Transparency does not provide
>> any way for Relying Parties to determine if a certificate corresponding to
>> a given precertificate has or has not been issued. It is only safe to
>> assume that a certificate corresponding to every precertificate exists.
>>
>> RFC 6962 states “The signature on the TBSCertificate indicates the
>> certificate authority's intent to issue a certificate.  This intent is
>> considered binding (i.e., misissuance of the Precertificate is considered
>> equal to misissuance of the final certificate).”
>>
>> However, BR 7.1.2.5 states “For purposes of clarification, a
>> Precertificate, as described in RFC 6962 – Certificate Transparency, shall
>> not be considered to be a “certificate” subject to the requirements of RFC
>> 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
>> Revocation List (CRL) Profile under these Baseline Requirements.”
>>
>> Mozilla interprets the BR language as a specific exception allowing CAs
>> to issue a precertificate containing the same serial number as the
>> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
>> a precertificate that a corresponding certificate has been issued.
>>
>> This means, for example, that:
>>
>> * A CA must provide OCSP services and responses in accordance with
>> Mozilla policy for all certificates presumed to exist based on the presence
>> of a Precertificate, even if the certificate does not actually exist
>> * A CA must be able to revoke a certificate presumed to exist, if
>> revocation of the certificate is required under Mozilla policy, even if the
>> certificate does not actually exist.
>> * If any corresponding certificate with the same serial number and issuer
>> exists, and can not be verified to match the precertificate using the
>> algorithms in RFC 6962, it will be considered misissued.
>> * In examining historical issuance, the CA must consider both final
>> certificates and precertificates, even if the precertificate did not
>> ultimately result in the issuance of a certificate.
>>
>
> I propose adding this language to our "Required Practices" wiki page [2],
> then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
> serial numbers. That still leaves some uncertainty about the use of the
> "unknown" response for precertificates (and in general), although Ryan made
> some good points about why using this status beyond the very narrow scope
> described in RFC 6960 section 2.2 is a bad idea.
>
> Once again, I will greatly appreciate your feedback on this topic. Since
> this is a practice and not official policy, I'll go ahead and update the
> wiki when I sense that we're in agreement here.
>
> - Wayne
>
> [1] https://cabforum.org/pipermail/public/2014-January/002694.html
> [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
>
> On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>>
>> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org > dev-security-policy@lists.mozilla.org>> wrote:
>> >
>> >>
>> >>
>> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> >> dev-security-policy@lists.mozilla.org> wrote:
>> >>>
>> >>> Hi Kurt.  I agree, hence why I proposed:
>> >>>
>> >>>  "- I would also like to see BR 4.9.10 revised to say something
>> roughly
>> >>> along these lines:
>> >>>   'If the OCSP responder receives a status request for a serial number
>> >>>that has not been allocated by the CA, then the responder SHOULD
>> NOT
>> >>>respond with a "good" status.’"
>> >>
>> >> I suppose one issue there is for CAs which allocate the serial number
>> very
>> >> early on in the issuance workflow - signing a dummy certificate with an
>> >> untrusted key, for instance, but not committing the CA to actually
>> >> producing either a pre-certificate or certificate (e.g, because the
>> >> applicant has insufficient funds to complete the process). It would not
>> >> seem correct to start answering 

Re: OCSP responder support for SHA256 issuer identifier info

[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.

But it stands to reason that the number of potential hash algorithms will 
generally be greater than the ability of OCSP responders to support them 
(especially in the case of CAs pregenerating responses); so the more general 
question seems to be “what is the optimal way to signal that the OCSP responder 
does not understand, or does not have a valid confirmation for, a given 
CertID.hashAlgorithm?”

Returning a response with an alternative CertID.hashAlgorithm (e.g. SHA-1) 
feels wrong; in order to validate the response, the client would have to 
recalculate the request using the “well known" hash algorithm - in which case, 
why didn’t it just send that query to the responder in the first place?

RFC 6960, Section 4.4.7.2.2 states "the responder SHOULD still use the
client request data during the selection of the pre-generated
response to be returned” - which would indicate that selection of an 
alternative CertID (even if semantically identical to the request) is viewed 
poorly.

“unauthorized” seems a valid view - it’s essentially saying “I don’t understand 
this Issuer specification”. Whether because of an unsupported hash algorithm, 
or a (name-hash, key-hash) value which does not map to a known issuer, it 
doesn’t really matter.

From my personal view, “malformedRequest” is also an acceptable return value - 
the text in RFC6960 gives the explanatory text “Illegal Confirmation Request” - 
which doesn’t in itself mean that the client sent a syntactically invalid OCSP 
request - merely that the parameters specified in that request cannot generate 
a successful answer from the OCSP responder.

So, from the original list of observed behaviours, 1, 4 and 5 seem OK by me.

Regards,

Neil

> On 19 Sep 2019, at 16:23, Curt Spann via dev-security-policy 
>  wrote:
> 
> 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 like the idea of agility for algorithms and it appears the RFCs 
> supports this by having a CertID.hashAlgorithm field.
> 
> - Curt
> 
>> On Sep 19, 2019, at 4:24 AM, Rob Stradling via dev-security-policy 
>>  wrote:
>> 
>> 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OCSP responder support for SHA256 issuer identifier info

[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. I like the idea of 
agility for algorithms and it appears the RFCs supports this by having a 
CertID.hashAlgorithm field.

- Curt

> On Sep 19, 2019, at 4:24 AM, Rob Stradling via dev-security-policy 
>  wrote:
> 
> 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 requirement for CertID.hashAlgorithm, and I would 
> (still [1]) prefer to see SHA-1 required and all other hash algorithms 
> forbidden.
> 
> Supporting stronger hash algorithms for CertID.hashAlgorithm would not 
> lead to any security gain, but it would inflict pain on those CAs that 
> need to regularly pregenerate OCSP responses (see [2]) for all unexpired 
> leaf certificates.
> 
> 
> [1] https://cabforum.org/pipermail/public/2013-November/002453.html 
> 
> 
> [2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2 
> 
> 
> On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote:
>> In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP 
>> requests using SHA256 for the issuerNameHash and issuerKeyHash. I have 
>> observed the following types of OCSP responses:
>> 1. “good” response with issuerNameHash and issuerKeyHash using SHA256
>> 2. “good” response with issuerNameHash and issuerKeyHash using SHA1
>> 3. “unknown” response containing the correct SHA256 issuerNameHash and 
>> issuerKeyHash but signed with an incorrect OCSP signing cert (chains to 
>> different authority)
>> 4. “unauthorized” response
>> 5. “malformedrequest” response
>> 
>> I would like to have a discussion with the community about what is thought 
>> to be the correct response. Of the various responses I have observed I think 
>> the correct response is number 1. I would also like to know if others have 
>> seen other variants of OCSP responses for request using SHA256 for the 
>> issuerNameHash and issuerKeyHash.
>> 
>> Supporting info
>> RFC 6960: https://tools.ietf.org/html/rfc6960
>> - 4.1.1.  ASN.1 Specification of the OCSP Request
>> RFC 2560: https://tools.ietf.org/html/rfc2560
>> - 4.1.1  Request Syntax
>> 
>> - Curt
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org 
> 
> https://lists.mozilla.org/listinfo/dev-security-policy 
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OCSP responder support for SHA256 issuer identifier info

[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 requirement for CertID.hashAlgorithm, and I would 
(still [1]) prefer to see SHA-1 required and all other hash algorithms 
forbidden.

Supporting stronger hash algorithms for CertID.hashAlgorithm would not 
lead to any security gain, but it would inflict pain on those CAs that 
need to regularly pregenerate OCSP responses (see [2]) for all unexpired 
leaf certificates.


[1] https://cabforum.org/pipermail/public/2013-November/002453.html

[2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2

On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote:
> In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP 
> requests using SHA256 for the issuerNameHash and issuerKeyHash. I have 
> observed the following types of OCSP responses:
> 1. “good” response with issuerNameHash and issuerKeyHash using SHA256
> 2. “good” response with issuerNameHash and issuerKeyHash using SHA1
> 3. “unknown” response containing the correct SHA256 issuerNameHash and 
> issuerKeyHash but signed with an incorrect OCSP signing cert (chains to 
> different authority)
> 4. “unauthorized” response
> 5. “malformedrequest” response
> 
> I would like to have a discussion with the community about what is thought to 
> be the correct response. Of the various responses I have observed I think the 
> correct response is number 1. I would also like to know if others have seen 
> other variants of OCSP responses for request using SHA256 for the 
> issuerNameHash and issuerKeyHash.
> 
> Supporting info
> RFC 6960: https://tools.ietf.org/html/rfc6960
> - 4.1.1.  ASN.1 Specification of the OCSP Request
> RFC 2560: https://tools.ietf.org/html/rfc2560
> - 4.1.1  Request Syntax
> 
> - Curt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy