Subject: [Spasm] An OCSP response extension

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 16:19:01 +0000

I would like to propose an OCSP response extension.  The intent is that a responder can include a human-readable annotation in an OCSP response. This is perhaps mainly for the responder auditors to use, and for simplicity/trade-off there are no language tags, etc.

id-pkix-ocsp-text OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }

re-ocsp-text EXTENSION { SYNTAX UTF8String
                                IDENTIFIED BY id-pkix-ocsp-text }

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Russ Housley <[email-masked]>
Date: Thu, 9 Mar 2017 11:24:33 -0500

Rich:

Can you give one example of the kind of human readable text that would be included in an OCSP response?

All:

If this were added to the LAMPS charter, would you implement it?

Russ

> On Mar 9, 2017, at 11:19 AM, Salz, Rich <[email-masked]> wrote:
> 
> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 16:40:12 +0000

> Can you give one example of the kind of human readable text that would be included in an OCSP response?

A ticket number, a URL, the name of the operator that did it, etc.

> If this were added to the LAMPS charter, would you implement it?

OpenSSL would almost definitely implement it.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 16:53:14 +0000

I've been asked off-list "why" ;)

If an OCSP responder is driven only from CRL's, then it is easy to correlate why a particular OCSP response has revoked/good in its status -- just find the appropriate CRL. But if a responder is driven by something like a WebUI, or has an API that lets keyholders revoke their own key (such as an ACME based CA might), then having a place to put additional information can be useful, if not required, to properly audit operations. I think this becomes more important as critical business applications are Web applications and OCSP stapling becomes the norm.

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Mar 2017 10:06:18 -0800

> If an OCSP responder is driven only from CRL's, then it is easy to correlate why a particular OCSP response has revoked/good in its status -- just find the appropriate CRL. But if a responder is dr…

Since the community is moving towards OCSP stapling and thus making
each bytes of OCSP more costly for performance, couldn't this extra
information simply be kept in CRLs for when it's needed? If machines
aren't going to use it, why send it thousands of times a second to all
clients?

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 18:07:45 +0000

> Since the community is moving towards OCSP stapling and thus making each
> bytes of OCSP more costly for performance, couldn't this extra information
> simply be kept in CRLs for when it's needed? If machines aren't going to use
> it, why send it thousands of times a second to all clients?

I'd only use it for revoked status.

A server could query its status and then fail to start with a useful message in the log, for example.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 10:08:30 -0800

It does seem like if an OCSP response is revoked you probably don't want to
send it to clients :)

-Ekr

On Thu, Mar 9, 2017 at 10:07 AM, Salz, Rich <[email-masked]> wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 18:12:54 +0000

> It does seem like if an OCSP response is revoked you probably don't want to send it to clients :)

So you'd think, but experience has shown us that this is not the case. :(  On both the client and server side.

---

From: Adam Langley <[email-masked]>
Date: Thu, 9 Mar 2017 10:31:28 -0800

> I'd only use it for revoked status.

Ah, I didn't get that point and, with that understanding, have no objection.

Cheers

AGL

---

From: Russ Housley <[email-masked]>
Date: Thu, 9 Mar 2017 14:19:03 -0500

> Ah, I didn't get that point and, with that understanding, have no objection.

If that is the intended us, I’d suggest:

id-pkix-ocsp-revoke-hint OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
 
re-ocsp-revoke-hint EXTENSION { SYNTAX UTF8String
                                IDENTIFIED BY id-pkix-ocsp-revoke-hint }
 
Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Mar 2017 22:46:33 +0000

>                                 IDENTIFIED BY id-pkix-ocsp-revoke-hint }

That makes a lot of sense to me.

---

From: Sean Turner <[email-masked]>
Date: Thu, 9 Mar 2017 21:13:09 -0500

>                                IDENTIFIED BY id-pkix-ocsp-revoke-hint }

If this is going to be get widely implemented should we look at updating RFC5019 which says:
"The responder SHOULD NOT include responseExtensions”?

spt

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 9 Mar 2017 22:15:24 -0500

> "The responder SHOULD NOT include responseExtensions”?

How do you see "widely implemented"?

I mentioned to Rich privately, but I think this is something that the
CA/Browser Forum should consider profiling out and expressly forbidding for
the time being, and if later ended up valuable (e.g. in the context of
must-staple certificates), would need to aggressively profile the
acceptable values suitable for the Web PKI.

In the context of other PKIs, however, I have no thought and experience to
inform on the value of that, which is why I was asking about "widely
implemented" - for example, if used by the FPKI or Grid PKI, would that be
"widely implemented"? If 5019 dropped the SHOULD NOT for that reason, would
the CA/B Forum need to profile it back in for the Web PKI?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Mar 2017 15:04:16 +0000

>"The responder SHOULD NOT include responseExtensions”?

Yes, the doc for this extension would update 5019 to at least lift it for this one.

Ryan:
>I mentioned to Rich privately, but I think this is something that the CA/Browser Forum should consider profiling out and expressly forbidding for the time being, and if later ended up valuable (e.g. in the context of must-staple certificates), would need to aggressively profile the acceptable values suitable for the Web PKI.

I think that's a mistake.  We'll never know it's valuable if you start by prohibiting it. I think there is value in a server having additional message from the responder that says *why* the certificate is not good.

If the doc defines this one extension and removes the prohibition *only for that extension* would you still feel it necessary to forbid it?

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 10:40:40 -0500

On Fri, Mar 10, 2017 at 10:04 AM, Salz, Rich <[email-masked]> wrote:

> I think that's a mistake.  We'll never know it's valuable if you start by
> prohibiting it. I think there is value in a server having additional
> message from the responder that says *why* the certificate is not good.
>

I disagree, because at least within the Web PKI, it's only valuable if it's
represented to the RP or if it can be automatically acted on. It's an
unnecessary detail for RPs, and it cannot be automatically acted upon
without normative specification of the contents. This is no different than
the Baseline Requirements profiling 5280 to specify how the CN, O, and OU,
or subjectAltName are normatively validated, so that there's a consistent
standard to the information presented and relied upon.

> If the doc defines this one extension and removes the prohibition *only
> for that extension* would you still feel it necessary to forbid it?
>

Yes

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Mar 2017 15:45:50 +0000

> I disagree, because at least within the Web PKI, it's only valuable if it's represented to the RP or if it can be automatically acted on.

Guidance to the server operator is very useful. At least within the webpki, there are more than just RP's, there are also severs. :)
 
>> If the doc defines this one extension and removes the prohibition *only for that extension* would you still feel it necessary to forbid it?

Hoping the cabal doesn't go that way.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 10:53:09 -0500

On Fri, Mar 10, 2017 at 10:45 AM, Salz, Rich <[email-masked]> wrote:

> > I disagree, because at least within the Web PKI, it's only valuable if
> it's represented to the RP or if it can be automatically acted on.
>
> Guidance to the server operator is very useful. At least within the
> webpki, there are more than just RP's, there are also severs. :)
>

I agree, but I disagree that guidance should be provided in a way that
negatively affects RPs. There's no need to force that information be
included to every RP who wants it, if it's only for the benefit of the
server operator. There's perfectly reasonable alternatives to solve that
concern, without conflating it with the RPs needs.

> Hoping the cabal doesn't go that way.

You mean try to make OCSP more effective for RPs by preventing CAs from
doing the equivalent of "Logotype" or "UserNotice" for OCSP - bloating
responses unnecessarily?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Mar 2017 16:15:38 +0000

> I agree, but I disagree that guidance should be provided in a way that negatively affects RPs. There's no need to force that information be included to every RP who wants it, if it's only for the benefit of the server operator. There's perfectly reasonable alternatives to solve that concern, without conflating it with the RPs needs.

Do servers normally send status-revoked OCSP responses as part of stapling?  Not in my experience; in yours?

> You mean try to make OCSP more effective for RPs by preventing CAs from doing the equivalent of "Logotype" or "UserNotice" for OCSP - bloating responses unnecessarily?

We disagree that this particular one is not useful or necessary.  And I never said the cabal didn’t do anything good.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 11:27:55 -0500

On Fri, Mar 10, 2017 at 11:15 AM, Salz, Rich <[email-masked]> wrote:

> Do servers normally send status-revoked OCSP responses as part of
> stapling?  Not in my experience; in yours?
>

Yes, actually. IIS will happily do this in my experience.

> We disagree that this particular one is not useful or necessary.  And I
> never said the cabal didn’t do anything good.

To be clear: The point I was making about the Forum profiling 5019 was to
make it clear not to set extensions. Similarly, with the introduction of an
extension that is only relevant for certain statuses, if the registration
didn't explicitly restrict it to specific status codes, the Forum would
need to profile it as such. And if the Forum were to allow it, it would
need to profile the values of it, so that it could/would be useful to site
operators and RPs.

The Forum's profile largely exists to take the giant bundle of
configurability that is the set of PKIX (and LAMPs) documents and tune it
for the least error prone. I think that's relatively uncontroversial, and
is not meant to be a rejection outright, but to highlight that the default
for any introduction of "a new option" is to ensure it's profiled out,
until there is consensus on whether and how it should be profiled in to the
Web PKI.

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Mar 2017 11:16:23 -0400

> On Mar 9, 2017, at 22:15, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> How do you see "widely implemented”?

I naively was thinking along the “worldly” level (aka WebPKI).

> In the context of other PKIs, however, I have no thought and experience to inform on the value of that, which is why I was asking about "widely implemented" - for example, if used by the FPKI or Grid PKI, would that be "widely implemented"? If 5019 dropped the SHOULD NOT for that reason, would the CA/B Forum need to profile it back in for the Web PKI?

So this is an interesting point and it’s kind of like when we looked at profiling OCSP for STIR (i.e., getting cert status for originators of digital signed SIP requests).  The HA OCSP profile was close to what we wanted so we use it as the base and then profiled stuff in (in some case back in and in some cases new stuff in).  If the HA OCSP profile had an applicability statement, which really nobody was doing back in the day, then it would be clear where it applied and where it didn’t.  I’m certainly not proposing anybody write up an applicability statement because well different communities can profile it as they see fit.  The only wrinkle here is that some communities are more hesitant than other to profile things back in because they get push back about being “non-standard,” but this might just have to go with the territory.

spt