Subject: [lamps] The id-ce-noRevAvail extension

From: Russ Housley <[email-masked]>
Date: Thu, 12 Nov 2020 10:24:01 -0500

Erik:

X.509 defines the id-ce-noRevAvail extension.  It was first referenced by RFC 3281 for use in attribute certificates,

>      name           id-ce-noRevAvail
>      OID            { id-ce 56 }
>      syntax         NULL (i.e. '0500'H is the DER encoding)
>      criticality    MUST be FALSE

X.509 says:  This extension shall not be included in public-key certificates or in attribute certificates issued to AAs. 

We do not seems to have an extension equivalent to id-ce-noRevAvail for public-key certificates.

With the move toward short lived public-key certificates, especially with the work in the IETF ACME WG, I wonder if X.509 can be changed to allow this extension to appear in end-entity public-key certificates.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2020 15:47:11 -0500

Russ Housley <[email-masked]> wrote:
    > X.509 defines the id-ce-noRevAvail extension.  It was first referenced
    > by RFC 3281 for use in attribute certificates,

I looked up the meaning:

   The noRevAvail extension, defined in [X.509-2000], allows an AC
   issuer to indicate that no revocation information will be made
   available for this AC.

    > X.509 says:  This extension shall not be included in public-key
    > certificates or in attribute certificates issued to AAs.

    > With the move toward short lived public-key certificates, especially
    > with the work in the IETF ACME WG, I wonder if X.509 can be changed to
    > allow this extension to appear in end-entity public-key certificates.

It seems like a good thing.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Nov 2020 16:00:29 -0500

On Thu, Nov 12, 2020 at 10:24 AM Russ Housley <[email-masked]> wrote:

> With the move toward short lived public-key certificates, especially with
> the work in the IETF ACME WG, I wonder if X.509 can be changed to allow
> this extension to appear in end-entity public-key certificates.
>

Under what processing model would such an extension be relevant for PKCs?
When a local client is configured to use an alternative source of
revocation (such as a locally-configured LDAP directory)?

It's not immediately obvious the value proposition of "affirmatively
asserting no" vs the status quo of "definitively not asserting any
information source", and under what processing model a client would find it
useful or important to distinguish these cases.

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Nov 2020 16:44:07 -0500

Ryan:

> On Thu, Nov 12, 2020 at 10:24 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Under what processing model would such an extension be relevant for PKCs? When a local client is configured to use an alternative source of revocation (such as a locally-configured LDAP directory)?

When an end-entity has a very short lifetime, the certificate will be expired before all of the steps can be performed to revoke it.  As you know, it takes time for the compromise to be discovered, reported, and the certificate is actually revoked.

> It's not immediately obvious the value proposition of "affirmatively asserting no" vs the status quo of "definitively not asserting any information source", and under what processing model a client would find it useful or important to distinguish these cases.

The difference is the processing time it takes for the RP to try to find information when the CA knows in advance that there never will be any.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Nov 2020 17:03:43 -0500

Russ Housley <[email-masked]> wrote:
    >> information source", and under what processing model a client would find
    >> it useful or important to distinguish these cases.

    > The difference is the processing time it takes for the RP to try to
    > find information when the CA knows in advance that there never will be
    > any.

It also has bearing to the EAP-TLS discussion in EMU about wither to
OCSP(staple) or not for industrial situations.

The RPs in question are EAP clients which do not have any connectivity (yet)
with which to attempt to find info.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Nov 2020 17:09:58 -0500

On Thu, Nov 12, 2020 at 4:44 PM Russ Housley <[email-masked]> wrote:

> The difference is the processing time it takes for the RP to try to find
> information when the CA knows in advance that there never will be any.
>

I'm sorry, I think you answered a different question than I was asking, so
I'll try to rephrase it using your response. I'm not asking about "why
would you use shortlived certificates", I'm trying to understand what you
see as the steps the RP takes to "try to find information", if no
references to such information are made available to the RP within the
certificate.

Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going
to find the information?

Is the assumption that the client will be performing LDAP directory checks
based on the DN of the cert, as envisaged in X.509v1?
Is the assumption that the client is locally configured to support some
local configuration that points to a repository with revocation?

In order for there to be steps that are skipped, there needs to be a
statement of what steps are performed. We can "obviously" disable CRLs and
OCSP by simply not providing such information in the certificate, so I was
hoping you could articulate what other sources of information that might be
used by a client where such an affirmative expression would be relevant and
necessary.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Nov 2020 17:11:25 -0500

> with which to attempt to find info.

"Find info" is the abstract hand-wave that I was hoping could be more
precisely elaborated on. If the certificate lacks a cRL DP and an OCSP AIA,
where is the client going to find info, and how does it know to go there,
and does any running code, in practice, actually do this?

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Nov 2020 00:51:24 -0500

On Thu, Nov 12, 2020 at 6:41 PM Mike Ounsworth <[email-masked]>
wrote:

> > Concretely: If a certificate lacks OCSP or CRLs in-band, where is it
> going to find the information?
>
> I’m not an OCSP expert, but a certificate without an OCSP AIA may still
> have an OCSP response stapled in the protocol?

Sure, but where does this information come from, and how does that relate
to "saving work", as proposed? Is a client expected to ignore such a
response, not even bothering to parse it? Would "stapling" an MPEG of a cat
as the OCSP response be a protocol violation, because it's not an OCSP
response? Or would it be working as intended, because the extension says to
ignore such responses? And is that a thing people have actually implemented
or would want to?

This also doesn't seem the scenario Russ was describing, given the remarks
about short-term certificates, so it seems like this is speculating about
some separate use case than what was originally presented. I'm not opposed
to speculation, but it seemed like there was a concrete case in mind?

> I have no personal experience with such a deployment, but I could imagine
> closed-network PKIs where that makes sense. An id-ce-noRevAvail type cert
> extension would allow an RP to distinguish between maliciously omitted OCSP
> responses, and certs that are not intended to have them.
>

If we're assuming the following scenario:
1) Server has an out-of-band configuration via some local policy on URLs
for a repository to obtain revocation information from the CA
2) The issued certificate lacks any references at all to these repositories
(e.g. no cRL DP, no OCSP AIA)
3) The client lacks such a locally-configured policy about that repository,
and thus relies entirely on the server to provide such information

And the goal is that if the client knows something affirmatively is not
revocable, it will ignore the stapled data provided, which presumably
would be something like a tryLater, or potentially a Good response valid
for the lifetime of the cert.  However, if it doesn't know it's not
revocable, then ... what, it'll fail the connection?

If that's the case, you can accomplish that same use case, today, by using
RFC 7633 to affirmatively indicate on the certificates you *do* provide
revocation information for that such information must be delivered by
stapling or the connection is failed, and any certificates omitting it have
the semantics of being presumed unrevocable, as the client lacks any
revocation details. That can be implemented today, without the need to
standardize any new extensions or define any processing semantics.

The problem I'm having is that while I can speculate on an endless number
of contrived cases (e.g. something that relies on the UNDETERMINED status
of RFC 5280, 6.3.3's outputs that would meaningfully lead to a different
behaviour than UNREVOKED, being able to skip looking up in LDAP for a CRL
based on the DN of the cert, being able to skip parsing previously obtained
CRL for that issuer, etc), I struggle to find a cohesive threat model or
use case that they actually address, that can't be accomplished via other
means, or that isn't tied to an unusual local policy configuration.

That's why I was interested in trying to find out why id-ce-noRevAvail is
seen as interesting for PKCs, and what it was that I was overlooking if
there was a non-contrived case. There also seems considerable security risk
in such extensions, much like what is discussed regarding
id-pkix-ocsp-nocheck, so I was surprised there would be interest in such a
remarkable footgun.

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 13 Nov 2020 07:48:21 +0100

On 2020-11-13 06:51, Ryan Sleevi wrote:
> 
> 
> On Thu, Nov 12, 2020 at 6:41 PM Mike Ounsworth
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > Concretely: If a certificate lacks OCSP or CRLs in-band, where is
>     it going to find the information?
> 
>     I’m not an OCSP expert, but a certificate without an OCSP AIA may
>     still have an OCSP response stapled in the protocol?
> 
> 
> Sure, but where does this information come from, and how does that
> relate to "saving work", as proposed? Is a client expected to ignore
> such a response, not even bothering to parse it? Would "stapling" an
> MPEG of a cat as the OCSP response be a protocol violation, because it's
> not an OCSP response? Or would it be working as intended, because the
> extension says to ignore such responses? And is that a thing people have
> actually implemented or would want to?
> 
> This also doesn't seem the scenario Russ was describing, given the
> remarks about short-term certificates, so it seems like this is
> speculating about some separate use case than what was originally
> presented. I'm not opposed to speculation, but it seemed like there was
> a concrete case in mind?
>  
> 
>     I have no personal experience with such a deployment, but I could
>     imagine closed-network PKIs where that makes sense. An
>     id-ce-noRevAvail type cert extension would allow an RP to
>     distinguish between maliciously omitted OCSP responses, and certs
>     that are not intended to have them.
> 
> 
> 2) The issued certificate lacks any references at all to these
> repositories (e.g. no cRL DP, no OCSP AIA)
> 3) The client lacks such a locally-configured policy about that
> repository, and thus relies entirely on the server to provide such
> information
> 
> If that's the case, you can accomplish that same use case, today, by
> using RFC 7633 to affirmatively indicate on the certificates you *do*
> provide revocation information for that such information must be
> delivered by stapling or the connection is failed, and any certificates
> omitting it have the semantics of being presumed unrevocable, as the
> client lacks any revocation details. That can be implemented today,
> without the need to standardize any new extensions or define any
> processing semantics.
> 
> The problem I'm having is that while I can speculate on an endless
> number of contrived cases (e.g. something that relies on the
> UNDETERMINED status of RFC 5280, 6.3.3's outputs that would meaningfully
> lead to a different behaviour than UNREVOKED, being able to skip looking
> up in LDAP for a CRL based on the DN of the cert, being able to skip
> parsing previously obtained CRL for that issuer, etc), I struggle to
> find a cohesive threat model or use case that they actually address,
> that can't be accomplished via other means, or that isn't tied to an
> unusual local policy configuration.
> 
> That's why I was interested in trying to find out why id-ce-noRevAvail
> is seen as interesting for PKCs, and what it was that I was overlooking
> if there was a non-contrived case. There also seems considerable
> security risk in such extensions, much like what is discussed regarding
> id-pkix-ocsp-nocheck, so I was surprised there would be interest in such
> a remarkable footgun.

My comment (supporting Ryan at this time) is that we should abstain from
adding more fields to certificates unless absolutely needed. Certificate
fields are hard for end users to configure right as it is, for all
various use cases they have. Every new field is a maintenance burden for
users and should imho only be added with crystal clear motivation.

Without a specific use case and benefit understood, for end devices to
not check revocation seems to be the most common modus operandi today.
Adding a field saying that devices should do what they already do seems
superfluous and overloads the already overloaded PKI administrators.

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2020 09:21:34 -0500

Ryan:

> On Thu, Nov 12, 2020 at 4:44 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> I'm sorry, I think you answered a different question than I was asking, so I'll try to rephrase it using your response. I'm not asking about "why would you use shortlived certificates", I'm trying to understand what you see as the steps the RP takes to "try to find information", if no references to such information are made available to the RP within the certificate.
> 
> Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going to find the information?
> 
> Is the assumption that the client will be performing LDAP directory checks based on the DN of the cert, as envisaged in X.509v1?
> Is the assumption that the client is locally configured to support some local configuration that points to a repository with revocation?
> 
> In order for there to be steps that are skipped, there needs to be a statement of what steps are performed. We can "obviously" disable CRLs and OCSP by simply not providing such information in the certificate, so I was hoping you could articulate what other sources of information that might be used by a client where such an affirmative expression would be relevant and necessary.

I have heard about several application, not in the Web PKI, where a very short lived certificate is being used.  In one extreme case, a key is generated, certified, used for one signature, and destroyed.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Nov 2020 09:55:02 -0500

On Fri, Nov 13, 2020 at 9:21 AM Russ Housley <[email-masked]> wrote:

> I have heard about several application, not in the Web PKI, where a very
> short lived certificate is being used.  In one extreme case, a key is
> generated, certified, used for one signature, and destroyed.
>
> Russ
>

Yes, I am also aware of such systems, and tried to acknowledge as much in
my previous messages.

However, this response is still a handwave that doesn’t address the very
real and practical question: how would such systems process certificates
differently in light of such an extension?

I’m not sure how to reword my question to make it clearer, but it’s the
same question I’ve been asking from the start.

I’m hoping to get you to describe a validation process - a set of inputs,
an algorithm, and outputs - where this extension would result in a
meaningful difference compared to just omitting OCSP AIA and CRL DPs. In
order for this to be useful, I imagine there has to be some algorithm that,
should this exist on PKCs, would produce a different output if all inputs
were the same, save for the existence of this extension. This is hopefully
a fairly basic question, but it’s vitally important to get a clear answer,
because it allows us to ask “are there other ways to get the same output”
(e.g. the omission of CRL DPs and OCSP AIA). Whether you want to frame it
in terms of proceeding of RFC 5280 Section 6, or frame it in terms of
running code that folks implement today, I’m ambivalent, but it’s essential
to discuss the desired output, since the claim is implicitly that there’s
no way to accomplish this today, and the extension is the only way.

If a behavior change is not desired, then is the view that this has no
semantic impact on processing, does not alter any semantic meaning, and is
merely a syntactical declaration by the CA? Such a declaration is
functionally equivalent to a comment in code, and meant to assist those who
manually inspect and personally review each certificate, rather than having
any bearing on code.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Nov 2020 15:12:02 +0000

*   Sure, but where does this information come from

Akamai allows its customers to configure the URL for OCSP responders.  Not many do so, of course, but those that use it want it badly.

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2020 10:17:21 -0500

> On Nov 13, 2020, at 9:55 AM, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> On Fri, Nov 13, 2020 at 9:21 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Ryan:
> 
> Yes, I am also aware of such systems, and tried to acknowledge as much in my previous messages.
> 
> However, this response is still a handwave that doesn’t address the very real and practical question: how would such systems process certificates differently in light of such an extension?

It would not look for a CRL or OCSP Responder.

> I’m not sure how to reword my question to make it clearer, but it’s the same question I’ve been asking from the start.
> 
> I’m hoping to get you to describe a validation process - a set of inputs, an algorithm, and outputs - where this extension would result in a meaningful difference compared to just omitting OCSP AIA and CRL DPs. In order for this to be useful, I imagine there has to be some algorithm that, should this exist on PKCs, would produce a different output if all inputs were the same, save for the existence of this extension. This is hopefully a fairly basic question, but it’s vitally important to get a clear answer, because it allows us to ask “are there other ways to get the same output” (e.g. the omission of CRL DPs and OCSP AIA). Whether you want to frame it in terms of proceeding of RFC 5280 Section 6, or frame it in terms of running code that folks implement today, I’m ambivalent, but it’s essential to discuss the desired output, since the claim is implicitly that there’s no way to accomplish this today, and the extension is the only way.

Some systems, especially ones with that use LDAP or X.500 Directory, look there for CRLs even if there is not a CRLDP extension.  This extension says to not do so.

> If a behavior change is not desired, then is the view that this has no semantic impact on processing, does not alter any semantic meaning, and is merely a syntactical declaration by the CA? Such a declaration is functionally equivalent to a comment in code, and meant to assist those who manually inspect and personally review each certificate, rather than having any bearing on code.

Russ

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 12 Nov 2020 23:41:13 +0000

> Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going to find the information?

I’m not an OCSP expert, but a certificate without an OCSP AIA may still have an OCSP response stapled in the protocol? I have no personal experience with such a deployment, but I could imagine closed-network PKIs where that makes sense. An id-ce-noRevAvail type cert extension would allow an RP to distinguish between maliciously omitted OCSP responses, and certs that are not intended to have them.

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <[email-masked]> On Behalf Of Ryan Sleevi
Sent: November 12, 2020 4:10 PM
To: Russ Housley <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; LAMPS <[email-masked]>; Erik Andersen <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________

On Thu, Nov 12, 2020 at 4:44 PM Russ Housley <mailto:[email-masked]> wrote:
It's not immediately obvious the value proposition of "affirmatively asserting no" vs the status quo of "definitively not asserting any information source", and under what processing model a client would find it useful or important to distinguish these cases.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Nov 2020 12:04:47 -0500

On Fri, Nov 13, 2020 at 10:17 AM Russ Housley <[email-masked]> wrote:

> Some systems, especially ones with that use LDAP or X.500 Directory, look
> there for CRLs even if there is not a CRLDP extension.  This extension says
> to not do so.
>

Thanks. I think we're finally making progress here. Can you point to any
examples of implementations that (still) allow for this? I realize this was
the dream of PKI in the late 90s/early 00s, but it seems very few, if any,
implementations support this, and it also seems to be far outside the realm
"Internet X.509", unless the thought is that the X.500 Global Directory is
finally just around the corner.

What is being described here, as with Rich's explanation, is, at its
core, "someone configures something according to local policy". And that
makes the proposal to use this extension, on PKCs, an extension to "Allow a
remote system to override local policy".

I don't believe that makes any sense at all, from a policy perspective. But
I also don't think it makes a good argument as to the necessity or benefit,
since in order for this extension to be useful, we already have to accept a
priori the ability of the device owner or administrator to configure
something via local policy. Since we're willing to entertain that yes,
there's local policy involved, it seems to reason that this capability can
also be addressed via local policy, without any such extension.

As I mentioned to Michael, it's reasonable to ask "How could we get the
same result, without the extension". And for the scenario you're raising
here, it stands to reason that the mere act of *not configuring that local
policy* is equally sufficient to address the need. Since the repository is
tied to a specific CA certificate, it's equally easy to imagine two
intermediates from the same (logical) root; one of the intermediates issues
certificates with revocation details available, and local policy configures
that directory URL, and the other intermediate issues these short-term
certificates, and local policy configures no such directory URL. That
solves the same problem, and leaving any security risks entirely up to
local policy.

I would oppose introducing this to PKCs, since the argument is to have a
"standard method", but that makes no sense at all, because it's a standard
method whose semantics only make sense according to local policy
configuration. I don't believe there is any interoperability "gain" from
having such an extension, given that it already depends on local policy.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Nov 2020 18:46:17 +0000

*   What is being described here, as with Rich's explanation, is, at its core, "someone configures something according to local policy". And that makes the proposal to use this extension, on PKCs, an extension to "Allow a remote system to override local policy".

No, my explanation was to point out that not all CA’s used in the WebPKI put OCSP AIA information in the certs they generate.

I support a CA being able to definitively say “we don’t post CRL or OCSP information” Whether or not an RP uses the extension is, of course, up to the RP.  You seem to be trying to show that this proposed extension is somehow different from that.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Nov 2020 14:12:13 -0500

On Fri, Nov 13, 2020 at 1:46 PM Salz, Rich <[email-masked]> wrote:

>
>    - What is being described here, as with Rich's explanation, is, at its
> No, my explanation was to point out that not all CA’s used in the WebPKI
> put OCSP AIA information in the certs they generate.
>

I'm not sure why you're referencing Web PKI - I certainly haven't - and I'm
not sure what you're trying to highlight that is different from what I said?

We can certainly talk about why this is beyond useless and borderline
harmful for Web PKI, but I saw that as a distraction. I'm more interested
in understanding how this fits into an RFC 5280 processing model, and how
that aligns with running code. To be clear, when i say running code, I'm
not restricting this to Web PKI. I'm trying to distinguish from the
abstract notion of PKI as tied to an X.500 directory, which few have
actually implemented, and fewer still use.

To your explanation: Yes, there are CAs that provide OCSP that don't place
it in certificates. My question has been to figure out where and how that
information is reaching RPs, since the purpose of this extension is to say
RPs should ignore that information. To wit, we've identified local policy
and configuration as an answer, which your previous reply I think
uncategorically shows. If that's not the case, I'm hoping you can explain
where else this information comes from, since we agree that it's not the
certificate.

> I support a CA being able to definitively say “we don’t post CRL or OCSP
> information” Whether or not an RP uses the extension is, of course, up to
> the RP.  You seem to be trying to show that this proposed extension is
> somehow different from that.
>

Is your point, then, that this extension should be present, but not affect
any processing whatsoever by the RP, in terms of RFC 5280 processing? If
so, what is the point and value to putting something in for RPs that RPs
cannot and do not use?

If you see RPs using this somehow to affect behavior, then again, I'd ask
you to clarify what behavior you'd like to see changed as a result of the
presence of this extension. That would at least allow a meaningful
exploration in how you can potentially already achieve that behavior,
without needing to "standardize" yet another way to accomplish the same
thing. [1]

[1] https://xkcd.com/927/

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 Nov 2020 15:57:15 +0000

*   I'm not sure why you're referencing Web PKI - I certainly haven't - and I'm not sure what you're trying to highlight that is different from what I said?

You’re right, I jumped to an assumption; mea culpa.

  *   To your explanation: Yes, there are CAs that provide OCSP that don't place it in certificates. My question has been to figure out where and how that information is reaching RPs, since the purpose of this extension is to say RPs should ignore that information. To wit, we've identified local policy and configuration as an answer, which your previous reply I think uncategorically shows. If that's not the case, I'm hoping you can explain where else this information comes from, since we agree that it's not the certificate.

No, this is correct.

  *   Is your point, then, that this extension should be present, but not affect any processing whatsoever by the RP, in terms of RFC 5280 processing? If so, what is the point and value to putting something in for RPs that RPs cannot and do not use?

My point is that, as with all 5280 extensions, an RP is free to use the semantic information in the extension, or not. Speaking for myself, and my employer, if we saw a cert with “no revocation information available” we’d honor it. :)  That means, we would ignore an possibly-stapled OCSP TLS data. Does that answer your question? For OpenSSL, I would expect that initially such a a cert would set a flag that applications can query and then, in a later release, the library itself would use that flag to skip CRL, OCSP checking, etc.  One of those crazy kids over there is going full-on into cert validation paths. But that’s just a guess.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 14 Nov 2020 15:04:34 -0500

On Sat, Nov 14, 2020 at 10:57 AM Salz, Rich <[email-masked]> wrote:

> My point is that, as with all 5280 extensions, an RP is free to use the
> semantic information in the extension, or not.
>

Sure, and there is a wide open space for private extensions, if they have
no discernable effect on processing. You could accomplish the same thing by
a certificate profile that said "OU = No Revocation Provided". Or by
stating it in a CP/CPS.

The point of putting something into an extension, particularly looking for
a standard one, is for when you want the RP to use that semantic
information, which means defining what those semantics are. And if you
actually think about what the semantics would be for this, my point is that
you can already accomplish that with existing capabilities, so there's no
point to standardizing in the first place a feature that would be
net-security-negative compared to those existing capabilities.

> Speaking for myself, and my employer, if we saw a cert with “no revocation
> information available” we’d honor it. :)  That means, we would ignore an
> possibly-stapled OCSP TLS data. Does that answer your question?
>

It opens more. I think that if you carry this through to its logical
consequence, you would also see this doesn't make sense.

For example, in the scenario you described where customers configure
explicit OCSP URLs that they obtain through some out-of-bands
(non-certificate) means, you could simply tell them "Don't do that". It's a
local policy thing that's saying "Do more work", and it's much easier to
just simply not set a local policy that says "do unnecessary work". This
extension would be effectively "stop hitting yourself", and that's silly.

Now, for the situation of stapled response, for a certificate that says "I
don't have revocation data", that's also silly. Either one of three things
is true here:
1) The CA actually provides revocation data, the stapled response is for
the cert, ergo the CA is a liar
2) The CA doesn't actually provide revocation data, the stapled response is
for some other cert, in which case, that should be a protocol error,
because it's stupid to let stupid servers send stupid things
3) The CA doesn't actually provide revocation data, the stapled response
isn't even an OCSP response in the first place, and that too should ... be
a protocol error.

This is why I argue it doesn't save work if you attach semantics to it, and
it doesn't make sense if you don't attach semantics.

> For OpenSSL, I would expect that initially such a a cert would set a flag
> that applications can query and then, in a later release, the library
> itself would use that flag to skip CRL, OCSP checking, etc.  One of those
> crazy kids over there is going full-on into cert validation paths. But
> that’s just a guess.
>

But, again, I don't think this makes any sense. What you're describing here
is the library has configured CRLs and OCSP servers, *outside* of the
certificate, and that such configuration doesn't make sense for the
certificate. The presumption here is that the library/author is
sufficiently knowledgeable to configure such sources, in which case, the
application author can totally simply configure themselves to not check
such responses for a particular CA, and that said particular CA only issue
these certificates.

To really argue for the extension to have value, you have to go even more
meta, by implicitly suggest that a single CA should be able to issue both
types of such certificates. Yet there's no actually compelling reason to
need that, given said CA can just use two separate issuing intermediates,
and things are fine. The only benefit to standardization is if we expect
this to be such a common case, that it would benefit from a standard and
interoperable implementations, such that developers don't have to configure
local policy. However, I think that's also nonsense, since to even get such
a CA in the first place, you.... depend on local policy.

This is what I mean by carrying through the use case through its logical
consequences. I totally acknowledge that there are a lot of assumptions
that are made in that previous paragraph, and you might be considering some
different case. But for all the unlisted permutations here of explanations
or constraints, it still seems that it'd be useless. So if there's a case
that's missing, some detail that actually makes it make sense and not just
yet another way to accomplish the same thing in PKI that we have a dozen
other ways of doing, that's what I'd be keen to learn.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2020 06:09:36 -0500

> net-security-negative compared to those existing capabilities.

As the person who raised this question about id-ce-noRevAvail in the
first place, i should probably say that i started off with the position
that Ryan Sleevi has here, and this conversation has only reinforced
that position for me.

I raised the question because i heard from another implementer that a
cert i created that had no OCSP and no CRL was failing on their system
because there was no way to verify its revocation status.  That other
implementer suggested that i might want to look into these extensions to
bypass such a check.  This policy (of requiring revocation checks even
when there is no indicator in the cert of how to find them) surprised
me, but i was game to look into it if it made life easier for other
implementers.

Now, after learning that neither of these two standards (no-CRL and
no-OCSP) are well-defined for this particular use case, i'm even more
inclined to think that that local policy is simply a bad idea and should
be discouraged, rather than changing any issuing policies.

      --dkg

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Nov 2020 03:25:08 -0500

Remember that this is part of the LAMPS WG charter:

1. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information. As a
result, revoking short-lived certificates is unnecessary and pointless.

Russ

> On Nov 12, 2020, at 10:24 AM, Russ Housley <[email-masked]> wrote:
> 
> Erik:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Nov 2020 12:35:35 -0500

> result, revoking short-lived certificates is unnecessary and pointless.

I agree that this is part of the charter.

I see two options for signalling that a certificate has no revocation
information available:

 (a) omit any mention of an OCSP responder or CRL location in the
     certificate itself.

or

 (b) explicitly specify the extensions id-ce-noRevAvail and
     id-pkix-ocsp-nocheck

(a) seems like it has the advantage of being simpler.  (b) seems to also
create an opportunity for confusion, because a single certificate can
now claim an OCSP responder, a CRL location, *and* specify these
locations.  What would that even mean?  Is this a new error case for
implementations to have to check for?

The only reason to push for (b) is if there is a legitimate case where a
standard policy mechanism needs to be *overridden* for a given
certificate.  For example, if there is a situation where the CRL
location or OCSP responder for a certificate is published in (and looked
for by the relying party in) the *issuer's* intermdiate CA certificate,
but is *not* expected to also be published in the certificate itself,
then we'd need (b) for the CA to be able to override the default
location.

Does such a standard policy exist?  I'm not an X.509 expert, so i don't
know about it.  If it does, a pointer to it would clarify the need for
(b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the
two options for finding the OCSP responder location are (1) in the
certificate itself whose status is being checked, or (2) "configured
locally at the OCSP client".

If the only scenario anyone can produce is "configured locally at the
OCSP client," then presumably such a policy requires identifying *which*
certificates to apply such an OCSP check to.

It seems like the solution for that use case is that local configuration
to match on a different set of certificates.  Introducing redundancy
(and room for error) in all certificates seems like a bad tradeoff for
local policy that could be updated independently.

      --dkg

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Nov 2020 12:58:17 -0500

DKG,

This determination should be based on how client behaves when no revocation
information can be obtained.  

As to OCSP client policy, clients can go to responder(s) that are locally
configured (causing delays) and come back with no tangible information.

The question boils down to do you want client to continue and without any
warning or anomaly?  If so, that should be indicated in the certificate and
not by omission of CRL DP and OCSP.  Again, the client needs to process that
indication to mean all is well.

I also do not see a need for both extensions.  No-check might not work with
COTS because some existing clients may deal with it for OCSP responder
delegated certificate.  

If this is a client you have control over, I would say you can make either
extension work.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] The id-ce-noRevAvail extension

or

(a) seems like it has the advantage of being simpler.  (b) seems to also
create an opportunity for confusion, because a single certificate can now
claim an OCSP responder, a CRL location, *and* specify these locations.
What would that even mean?  Is this a new error case for implementations to
have to check for?

The only reason to push for (b) is if there is a legitimate case where a
standard policy mechanism needs to be *overridden* for a given certificate.
For example, if there is a situation where the CRL location or OCSP
responder for a certificate is published in (and looked for by the relying
party in) the *issuer's* intermdiate CA certificate, but is *not* expected
to also be published in the certificate itself, then we'd need (b) for the
CA to be able to override the default location.

Does such a standard policy exist?  I'm not an X.509 expert, so i don't know
about it.  If it does, a pointer to it would clarify the need for (b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two
options for finding the OCSP responder location are (1) in the certificate
itself whose status is being checked, or (2) "configured locally at the OCSP
client".

If the only scenario anyone can produce is "configured locally at the OCSP
client," then presumably such a policy requires identifying *which*
certificates to apply such an OCSP check to.

It seems like the solution for that use case is that local configuration to
match on a different set of certificates.  Introducing redundancy (and room
for error) in all certificates seems like a bad tradeoff for local policy
that could be updated independently.

      --dkg

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Nov 2020 19:05:35 -0500

Mike,

Recursion in OCSP check is avoided by simply asserting OCSP-nocheck in
delegated OCSP Responder certificate.

noRevAvail obviates revocation checking for attribute certificate.

Neither fit a TLS Server, TLS Client or E-Mail client.  It will all be a
function of how relying party software behaves if either one works.  I
suppose asserting both is saying I hope RP gets one of the two in the
context of a certificate which is neither attribute certificate nor
delegated OCSP Responder certificate.

I would like to review DKG I-D and I-D scope to figure out if I can provide
any helpful suggestion.

-----Original Message-----
From: Mike Ounsworth [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2020 6:48 PM
To: Santosh Chokhani <[email-masked]>; 'LAMPS' <[email-masked]>
Subject: RE: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

Unless I'm missing something, another concrete use-case for allowing
id-ce-noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow OCSP
over HTTPS (unless there's another way that I'm not aware of to break the
recursive OCSP checks loop). Clients for this use case would be "anything
web".

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Santosh Chokhani
Sent: November 17, 2020 11:58 AM
To: 'LAMPS' <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.

DKG,

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] The id-ce-noRevAvail extension

or

      --dkg

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

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 17 Nov 2020 23:47:31 +0000

Unless I'm missing something, another concrete use-case for allowing id-ce-noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow OCSP over HTTPS (unless there's another way that I'm not aware of to break the recursive OCSP checks loop). Clients for this use case would be "anything web".

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Santosh Chokhani
Sent: November 17, 2020 11:58 AM
To: 'LAMPS' <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

DKG,

This determination should be based on how client behaves when no revocation information can be obtained.  

As to OCSP client policy, clients can go to responder(s) that are locally configured (causing delays) and come back with no tangible information.

The question boils down to do you want client to continue and without any warning or anomaly?  If so, that should be indicated in the certificate and not by omission of CRL DP and OCSP.  Again, the client needs to process that indication to mean all is well.

I also do not see a need for both extensions.  No-check might not work with COTS because some existing clients may deal with it for OCSP responder delegated certificate.  

If this is a client you have control over, I would say you can make either extension work.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] The id-ce-noRevAvail extension

I see two options for signalling that a certificate has no revocation information available:

or

(a) seems like it has the advantage of being simpler.  (b) seems to also create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations.
What would that even mean?  Is this a new error case for implementations to have to check for?

The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate.
For example, if there is a situation where the CRL location or OCSP responder for a certificate is published in (and looked for by the relying party in) the *issuer's* intermdiate CA certificate, but is *not* expected to also be published in the certificate itself, then we'd need (b) for the CA to be able to override the default location.

Does such a standard policy exist?  I'm not an X.509 expert, so i don't know about it.  If it does, a pointer to it would clarify the need for (b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two options for finding the OCSP responder location are (1) in the certificate itself whose status is being checked, or (2) "configured locally at the OCSP client".

If the only scenario anyone can produce is "configured locally at the OCSP client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to.

It seems like the solution for that use case is that local configuration to match on a different set of certificates.  Introducing redundancy (and room for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently.

      --dkg

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 18 Nov 2020 00:13:34 +0000

Hi Santosh. 

I'm not talking about the delegated OCSP Responder cert (ie the thing signing OCSP responses), but rather the TLS cert on the webserver sitting in front of the OCSP Responder. That means you could put an HTTPS URL in the OCSP AIA. It means we wouldn't have the OCSP endpoint be HTTP when everything else is HTTPS.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Santosh Chokhani
Sent: November 17, 2020 6:06 PM
To: 'LAMPS' <[email-masked]>
Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension

Mike,

Recursion in OCSP check is avoided by simply asserting OCSP-nocheck in delegated OCSP Responder certificate.

Neither fit a TLS Server, TLS Client or E-Mail client.  It will all be a function of how relying party software behaves if either one works.  I suppose asserting both is saying I hope RP gets one of the two in the context of a certificate which is neither attribute certificate nor delegated OCSP Responder certificate.

I would like to review DKG I-D and I-D scope to figure out if I can provide any helpful suggestion.

-----Original Message-----
From: Mike Ounsworth [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 6:48 PM
To: Santosh Chokhani <[email-masked]>; 'LAMPS' <[email-masked]>
Subject: RE: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Santosh Chokhani
Sent: November 17, 2020 11:58 AM
To: 'LAMPS' <[email-masked]>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

DKG,

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Subject: Re: [lamps] The id-ce-noRevAvail extension

or

      --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 18 Nov 2020 07:12:13 -0500

I think you might be missing something, because as I explained, and as DKG
mentioned, the omission of such information within a certificate is
sufficient.

If you believe there is a necessity for an extension, you need to describe
a processing model of RFC 5280 that behaves differently. This should be a
hopefully easy exercise.

On Wed, Nov 18, 2020 at 1:32 AM Mike Ounsworth <Mike.Ounsworth=
[email-masked]> wrote:

> id-ce-noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow
> OCSP over HTTPS (unless there's another way that I'm not aware of to break
> the recursive OCSP checks loop). Clients for this use case would be
> "anything web".
>
> ---
> Mike Ounsworth
>
> not by omission of CRL DP and OCSP.  Again, the client needs to process
> that indication to mean all is well.
>
> I also do not see a need for both extensions.  No-check might not work
> with COTS because some existing clients may deal with it for OCSP responder
> delegated certificate.
>
> know about it.  If it does, a pointer to it would clarify the need for (b).
>
> to match on a different set of certificates.  Introducing redundancy (and
> room for error) in all certificates seems like a bad tradeoff for local
> policy that could be updated independently.
>
>       --dkg
>

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 18 Nov 2020 07:33:46 -0500

Santosh,

This doesn’t really explain the necessity for an extension, and I’m hoping
that if you believe it necessary, you can describe a concrete processing
model where it does, with reference to RFC 5280.

There are several critical assumptions here that you haven’t actually
elaborated on:

1. That a client will have a different output based on the presence of this
extension than without.

Can you describe, tangibly, what those outputs are, and how that fits with
today’s RFC 5280 processing model, since you clearly make reference to this
possibility?

2. That clients, which are updated to support whatever semantics #1
proposes, have no other way of achieving this result.

The problem here is that in order for an extension to be useful, it needs
to have new semantics (#1), which means the client must update to support
that extension. Since we have to assume the client can update, it doesn’t
make any sense to suggest this is the only possible solution.

3. That this is a matter for CA expression, and not local policy.

>From what you describe, there’s a clear desire that client behavior should
change (#1) based on some direction of the CA (#2). However, honestly and
fully answering #2 requires us to also ask: is this something that the CA
should be defining in the first place, or is this really a matter for local
policy?

To understand this, consider if we assume that there is some
(yet-undefined) processing model associated to the semantics of putting it
into an extension, and all clients are updated to these semantics. This
extension is now present in a CA certificate valid for 30 years. Should the
client trust that CA or, since it expects revocation details, reject it? I
should hope the answer is “reject”. What about if this was an EE cert,
valid for 1y? Again, I would hope the answer is reject.

What this means is that, even assuming the extension and semantics, there’s
some local policy involved which cannot simply blindly trust the CA and go
“well, they said no revocation would ever be available, and that’s fine by
me,” because to do so would be laughably insecure. So whether or not a CA
is permitted to definitively not provide revocation details then has to
consider local policy about when that is acceptable, which means that the
CA’s explicit expression doesn’t override or replace local policy. Since
local policy is now involved (answering #3), it means we have more options
to solve (#2), including that clients simply update to handle omitted
revocation details to whatever preferred semantics for #1 .

So no, I don’t see the necessity of an explicit extension here.

On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani <
[email-masked]> wrote:

> know
> two

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 18 Nov 2020 08:09:00 -0500

Ryan,

It all depends on what the client does.  Clearly OCSP RFC authors thought it
useful to indicate this.  They could have used your rationale.

As I mentioned it all depends on if you are in control of the client
consuming these certificates.

If you are talking about all the X.509 enabled clients out there today, then
you are right, the behavior will be varied as clients are and we do not
clear.

If you want to do something for a client you design for this class of
certificates, I would recommend parking on OCSP-nocheck since its
description in RFC 6960 is closer to what you are saying.

From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Wednesday, November 18, 2020 7:34 AM
To: Santosh Chokhani <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] The id-ce-noRevAvail extension

Santosh,

This doesn't really explain the necessity for an extension, and I'm hoping
that if you believe it necessary, you can describe a concrete processing
model where it does, with reference to RFC 5280.

There are several critical assumptions here that you haven't actually
elaborated on:

Can you describe, tangibly, what those outputs are, and how that fits with
today's RFC 5280 processing model, since you clearly make reference to this
possibility?

The problem here is that in order for an extension to be useful, it needs to
have new semantics (#1), which means the client must update to support that
extension. Since we have to assume the client can update, it doesn't make
any sense to suggest this is the only possible solution.

>From what you describe, there's a clear desire that client behavior should

To understand this, consider if we assume that there is some (yet-undefined)
processing model associated to the semantics of putting it into an
extension, and all clients are updated to these semantics. This extension is
now present in a CA certificate valid for 30 years. Should the client trust
that CA or, since it expects revocation details, reject it? I should hope
the answer is "reject". What about if this was an EE cert, valid for 1y?
Again, I would hope the answer is reject.

What this means is that, even assuming the extension and semantics, there's
some local policy involved which cannot simply blindly trust the CA and go
"well, they said no revocation would ever be available, and that's fine by
me," because to do so would be laughably insecure. So whether or not a CA is
permitted to definitively not provide revocation details then has to
consider local policy about when that is acceptable, which means that the
CA's explicit expression doesn't override or replace local policy. Since
local policy is now involved (answering #3), it means we have more options
to solve (#2), including that clients simply update to handle omitted
revocation details to whatever preferred semantics for #1 .

So no, I don't see the necessity of an explicit extension here.

On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani
<[email-masked] <mailto:[email-masked]> > wrote:

DKG,

-----Original Message-----
From: Spasm [mailto:[email-masked] <mailto:[email-masked]> ]
On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <[email-masked] <mailto:[email-masked]> >;
LAMPS <[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] The id-ce-noRevAvail extension

or

      --dkg

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 18 Nov 2020 08:49:46 -0500

On Wed, Nov 18, 2020 at 8:09 AM Santosh Chokhani <[email-masked]>
wrote:

> Ryan,
>
>
>
> It all depends on what the client does.  Clearly OCSP RFC authors thought
> it useful to indicate this.  They could have used your rationale.
>
This is just an argument to authority that doesn’t actually establish any
new information, and itself rests on disproven assumptions about how things
would work (“the directory!”, “reliable connectivity”, “hard fail”).

It is the misguided efforts there that inform my criticism, exactly because
clients have found necessary to impose local policy on such information,
and to otherwise disregard such information, as appropriate.

> consuming these certificates.
I think we agree here, but I can’t help but feel like you’re arguing for a
hypothetical “what if clients...”, and I’m trying to highlight that if
we’re entertaining hypotheticals, there are far more practical ways to
achieve the implied desired result.

However, if we want to continue to entertain such hypotheticals, we need to
explicitly state whatever assumptions exist that make this useful, if
staying this extension is useful.

>
> If you are talking about all the X.509 enabled clients out there today,
> then you are right, the behavior will be varied as clients are and we do
> not clear.
>
>
>
And I’m stating that if you want something for a client you design for this
class of certificates, you can just as easily decide, in your client, to
not hard-fail on the absence of the CDP and AIA. Which, incidentally, is
the behavior of virtually every implementation out there, since the assumed
behavior that made noCheck necessary (hard fail and local client
configuration to a local directory) achieved neither “rough consensus” nor
“running code”. So you don’t have to design as if these are inherently
true, since in the vast majority of the time, they aren’t, and for good
reason.

>
> *From:* Ryan Sleevi [mailto:[email-masked]]
> *Sent:* Wednesday, November 18, 2020 7:34 AM
> *To:* Santosh Chokhani <[email-masked]>
> *Cc:* LAMPS <[email-masked]>
> *Subject:* Re: [lamps] The id-ce-noRevAvail extension
>
>
>
> Santosh,
>
>
>
> 1. That a client will have a different output based on the presence of
> this extension than without.
>
>
>
> What this means is that, even assuming the extension and semantics,
> there’s some local policy involved which cannot simply blindly trust the CA
> and go “well, they said no revocation would ever be available, and that’s
> fine by me,” because to do so would be laughably insecure. So whether or
> not a CA is permitted to definitively not provide revocation details then
> has to consider local policy about when that is acceptable, which means
> that the CA’s explicit expression doesn’t override or replace local policy.
> Since local policy is now involved (answering #3), it means we have more
> options to solve (#2), including that clients simply update to handle
> omitted revocation details to whatever preferred semantics for #1 .
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 19:04:30 +0000

*   I think you might be missing something, because as I explained, and as DKG mentioned, the omission of such information within a certificate is sufficient.

I disagree for reasons as I described.  In addition, an RP might have a global list of OCSP responder configured.

  *   If you believe there is a necessity for an extension, you need to describe a processing model of RFC 5280 that behaves differently. This should be a hopefully easy exercise.

If the extension is specified, then the CA indicates that revocation information, such as OCSP or CRLs, will not be provided. Relying parties are free to use and process any such information they have available to them. IF the extension is marked CRITICAL than relying parties MUST NOT use such information.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 14:08:33 -0500

[CW] It is none of the CA’s business if I elect to consider a certificate revoked.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 19:33:23 +0000

*   [CW] It is none of the CA’s business if I elect to consider a certificate revoked.

Sure, you can do whatever out of band processing you want.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 14:42:52 -0500

Then I mistook your “IF the extension is marked CRITICAL than relying parties MUST NOT use such information” as standards language to the contrary.

From: "Salz, Rich" <[email-masked]>
Date: Wednesday, November 18, 2020 at 2:33 PM
To: Carl Wallace <[email-masked]>, Ryan Sleevi <[email-masked]>, Mike Ounsworth <[email-masked]>
Cc: LAMPS <[email-masked]>, Santosh Chokhani <[email-masked]>
Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 19:44:19 +0000

*   Then I mistook your “IF the extension is marked CRITICAL than relying parties MUST NOT use such information” as standards language to the contrary.

Anything out of band, like your personal magic 8 ball, is out of scope for 5280 processing rules.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 14:58:49 -0500

[CW] The MUST NOT in your proposed definition certainly appears to try to tell me what to do with my personal magic 8 ball: “Relying parties are free to use and process any such information they have available to them. IF the extension is marked CRITICAL than relying parties MUST NOT use such information.” I agree this is out of scope of 5280 processing rules and suggest that it is out of scope for standardizing at all (so we don’t need the proposed definition). +1 for Ryan Sleevi’s notes throughout this thread.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 20:01:03 +0000

> I agree this is out of scope of 5280 processing rules

How do you feel bout OCSP-must-check?  How do you feel about following all AIA values?

> suggest that it is out of scope for standardizing at all (so we don’t need the proposed definition).

We need it standardized so that multiple parties – all the RP’s, all the CA’s and all the customers – have common expectations.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 15:05:51 -0500

[CW] We do not need “MUST NOT process when critical” with regard to this, which is the point I chimed in on. Do you agree with that? On the bigger points, as noted, I agree with others that absence of AIA and CRL DP is sufficient. I could see where one might want to write a few words on what absence of those extensions means but don’t see the need for another extension.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 20:09:18 +0000

*   CW] We do not need “MUST NOT process when critical” with regard to this, which is the point I chimed in on. Do you agree with that? On the bigger points, as noted, I agree with others that absence of AIA and CRL DP is sufficient. I could see where one might want to write a few words on what absence of those extensions means but don’t see the need for another extension.

I’m willing to leave that to wordsmithing negotiation.  How about SHOULD NOT ?  But I don’t care greatly.

We see CA’s in public use that do not populate all certificates with AIA information, so the absence of that info is not sufficient.  We need a positive signal.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 15:24:06 -0500

[CW] This has now veered back into discussion that has already taken place. The earlier notes requested standards language. The proposed standards language quickly arrived at a point where it didn’t make sense (i.e., telling me I must or should not do something while conceding I can do what I want). Aside from the difficulty of the meaning of critical, the proposed standards language should address how the feature is introduced and what absence of the positive signal means in a certificate without AIA or CRL DP. To some extent this is kind of like the introduction of basic constraints. Maybe this requires X.509 v4:-)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 20:27:51 +0000

>CW] This has now veered back into discussion that has already taken place. The earlier notes requested standards language. The proposed standards language quickly arrived at a point where it didn’t make

I was trying to be accommodating and I guess I should not have done so.

I prefer the language I first proposed.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 16:55:17 -0500

[CW] How about instead of the positive statement that no revocation info is available paired with absence of AIA and CRL DP, you define an extension that says “yes, I have revocation info but I’m not telling you where it is in this certificate” for the CAs that follow that particular practice? That would leave absence of AIA and CRL DP with the semantics already suggested by others.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 22:01:08 +0000

> That would leave absence of AIA and CRL DP with the semantics already suggested by others.

Except that those semantics being suggested don’t hold to be true in our experience.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Nov 2020 22:07:37 +0000

>> That would leave absence of AIA and CRL DP with the semantics already suggested by others.

  *   Except that those semantics being suggested don’t hold to be true in our experience.

For example, a rough count [1] shows 71,000 such certs.

[1] https://censys.io/certificates?q=zlint.lints.e_sub_ca_aia_does_not_contain_ocsp_url%3A+true

---

From: Carl Wallace <[email-masked]>
Date: Wed, 18 Nov 2020 17:13:24 -0500

I tried to offer a counter approach. I guess I shouldn’t have. I prefer to not have extension to restate that revocation info pointers are not provided. Let’s leave it there. 

> On Nov 18, 2020, at 5:07 PM, Salz, Rich <[email-masked]> wrote:
> 
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Nov 2020 21:18:26 -0500

> [1] https://censys.io/certificates?q=zlint.lints.e_sub_ca_aia_does_not_contain_ocsp_url%3A+true

These are intermediate CA certs that don't contain OCSP urls.

the zlint label e_sub_ca_aia_does_not_contain_ocsp_url suggests a
violation of Baseline Requirement: 7.1.2.2: "Subordinate CA certificates
authorityInformationAccess extension must contain the HTTP URL of the
issuing CA’s OCSP responder"

So let's dig into the first example (in my view of the above list
anyway), which is "Swisscom Rubin CA 1":

https://censys.io/certificates/86053117868a2582946790714db09b2c84c46299fe008bc96b1f60a8119855e2

it is issued by "Swisscom Root CA 1", a root CA trusted by Mozilla,
Microsoft, and Apple:

https://censys.io/certificates/21db20123660bb2ed418205da11ee7a85a65e2bc6e55b5af7e7899c8a266d92e

Assuming i'm understanding the censys data correctly, it looks like none
of the immediate children of "Swisscom Root CA 1" have *any* OCSP
responder URL listed.  Maybe that means that this is a root CA that just
doesn't run an OCSP responder?  (it does offer a CRL, and all of the
intermediates i looked at did point to that CRL)

So this just means that these intermediate CA certs would be in
violation of the baseline requirements, so maybe none of them would be
acceptable as an intermediate CA if (for example) the relying party's
local policy dictates that intermediate CA certificates should be
rejcted if they violate BR 7.1.2.2.

But the inclusion of an id-pkix-ocsp-nocheck extension wouldn't somehow
make the certificate suddenly comply with BR 7.1.2.2, right?  it would
still be lacking an OCSP responder AIA, so this particular local policy
wouldn't be affected by the presence (or absence) of the extension --
we've already got the information we need for it in the certificate
itself.

Is there an example of a real world local policy for relying parties
that would make use of this field, then i'd like to know about it.  If
there isn't one, then i don't understand why we should promote a new
extension.

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Nov 2020 20:52:15 -0500

Hi Rich--

On Wed 2020-11-18 19:04:30 +0000, Salz, Rich wrote:
> If the extension is specified, then the CA indicates that revocation
> information, such as OCSP or CRLs, will not be provided. 

Thanks for trying to help me understand your use case here.  I'm afraid
i still don't get it -- or at least, i think i understand what might be
happening in some RPs that have decided to look up revocation
information someplace not specified in the cert.  But i don't see why
the choices of those RPs warrant introducing potential redundancy and
inconsistency for *all* RPs, subscribers, and issuers.

Doesn't the lack of OCSP and CRL location information in the certificate
communicate the same information?

> Relying parties are free to use and process any such information they
> have available to them.

Surely this is the case always, regardless of what's in the certificate.

> IF the extension is marked CRITICAL than relying parties MUST NOT use
> such information.

This is not the semantics of criticality that i expect.  I thought that
marking an X.509 extension as critical meant "if you don't know how to
interpret this extension, you MUST NOT accept this certificate".  But if
you *do* know how to interpret the extension, then the criticality of
the extension is irrelevant; you are simply expected to take its
semantics into account during your validation process.

That is, "criticality" means "don't skip this bit just because you don't
understand it: if you do, you risk getting burned".

But maybe i've inherited this understanding of criticality from some
other space (e.g. OpenPGP subpacket bit 7, see RFC 4880 §5.2.3.1), and
maybe it's not a valid read of criticality for X.509v3.  Are there
examples where criticality actually alters the semantics of an X.509v3
extension for relying parties that *do* understand the extension?

          --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2020 04:03:04 +0000

>    These are intermediate CA certs that don't contain OCSP urls.

All of them?  I couldn't figure out how to say "and not a CA".

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2020 04:13:21 +0000

happening in some RPs that have decided to look up revocation
    information someplace not specified in the cert.

If all origins were as informed and diligent as those of us in this community, it would probably not be needed. But they are not, and we see origin certs without OCSP AIA. Or people say "I don't know, ask the CA" etc.

> But i don't see why

I don't understand the inconsistency argument. Are you saying that there are no end-entity certs used in TLS that do not mistakenly have missing AIA fields?   Also see next paragraph.

I do not see anything in RFC 5280 sec 4.2.2.1 that says the OCSP AIA is the *only* place where OCSP responder information should be found. The argument that some are making "if it's not in the OCSP AIA there is no OCSP responder" does not seem supported by the text. Perhaps I am misreading it, or should look to errata or other RFC's -- please point me to them.

Yes, you kind of have to squint to treat criticality as I described it. Maybe squint so much you can't even see the text, I admit :)

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 18 Nov 2020 23:44:22 -0500

On Wed, Nov 18, 2020 at 11:13 PM Salz, Rich <[email-masked]> wrote:

> I don't understand the inconsistency argument. Are you saying that there
> are no end-entity certs used in TLS that do not mistakenly have missing AIA
> fields?   Also see next paragraph.
>

This seems an entirely orthogonal discussion?

> I do not see anything in RFC 5280 sec 4.2.2.1 that says the OCSP AIA is
> the *only* place where OCSP responder information should be found. The
> argument that some are making "if it's not in the OCSP AIA there is no OCSP
> responder" does not seem supported by the text. Perhaps I am misreading it,
> or should look to errata or other RFC's -- please point me to them.
>

I'm not sure if you're lumping me in that "some", but I've repeatedly
acknowledged this scenario as being precisely why what you're proposing
doesn't make sense.

There are, in effect, three possible sources for OCSP information:
1. The AIA of the certificate
2. The Directory object associated with the DN of the certificate
3. Local Policy

The absence of 1. is our first sign that the CA has decided not to provide
OCSP information. 2 is just... not a thing in polite society, although I'm
sure ITU-T adherents might suggest otherwise.

So really, the source of that is 3.

You gave one such illustration of 3, when you stated "In addition, an RP
might have a global list of OCSP responder configured.". There, an RP has a
local policy that (presumably) is some mapping of DN to OCSP URL, although
strictly speaking, it could just be *one* OCSP URL (ah OCSP, how complex
and fickle you are).

Yet in that situation, we have an RP making a decision, independent of the
CA, to unilaterally check OCSP. That is a local policy (mis)configuration,
and if a local policy does this, then I fail to see why local policy would
or should respect what the CA says.

Now, if we assume this extension existed, then we also have to assume that
the client will update to support this local policy, and apriori agree with
the CA to make use of this extension to indicate such a scenario. That is,
both local policy AND software must be changed to support this scenario.

Yet, if that's our goal, we can accomplish the same thing without any
software change on the RP side. Given that, in order for this extension to
have any relevance in the presence of misconfigured local policy, the RP
and the CA must agree out-of-band to use this extension, we have to
acknowledge that the RP and the CA have some form of relationship. A CA can
just as equally divide the "certs for which we provide no OCSP information
for" and the "certs for which we do" into two separate subordinate
hierarchies (that is, two different issuer DNs). Then our plucky, but
misguided, local RP, they simply have to omit providing a URL for the DN of
the CA that doesn't provide revocation information.

Put differently, this mess only exists because of 2 or 3, and cannot exist
because of 1 (at least, as presently described). Because both 2 and 3 are
matters of local policy, any undesirable effect is self-inflicted, but
equally, any intended or desired semantics are locally defined. The RP can
simply *stop doing that silliness* (like a global set of OCSP URLs),
because that's definitely in Fringe PKI territory where it's already
non-interoperable, since other RPs that don't do that local policy aren't
able to obtain revocation information because of that.

> Yes, you kind of have to squint to treat criticality as I described it.
> Maybe squint so much you can't even see the text, I admit :)
>

I mean, I would argue that redefining it to the point of incompatible :)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2020 06:19:53 +0000

>The absence of 1. is our first sign that the CA has decided not to provide OCSP information

I was not including you in the “some”  I was including you in the question about where RFC 5280 says “not having AIA means there’s no responder”  So please, tell me how you get to #1?  You often wrote “in the context of RFC 5280 processing rules”  So please point me to the rule?

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 19 Nov 2020 02:33:27 -0500

On Thu, Nov 19, 2020 at 1:20 AM Salz, Rich <[email-masked]> wrote:

> *>*There are, in effect, three possible sources for OCSP information:
>
> I was not including you in the “some”  I was including you in the question
> about where RFC 5280 says “not having AIA means there’s no responder”  So
> please, tell me how you get to #1?  You often wrote “in the context of RFC
> 5280 processing rules”  So please point me to the rule?
>

I'm not sure how to entirely interpret your question. "If the CA has not
said something, how do you know the CA has not said something?"

Judging by your reaction, I suspect you may have interpreted my statement
to mean "If the CA has not provided an OCSP URL, it has authoritatively
stated unambiguously it will not provide OCSP", which was certainly not the
meaning I was trying to convey. Rather, it was meant to highlight that if
the CA has not declared something in the certificate, then within the
processing model of RFC 5280, the CA has not directed the client to do
something, nor has it committed to the client that it will make something
available.

That said, this is supported by the text:

https://tools.ietf.org/html/rfc5280#section-4.2.2.1
>    The id-ad-ocsp OID is used when revocation information for the
>   certificate containing this extension is available using the Online
>   Certificate Status Protocol (OCSP) [RFC2560].

The corollary of that is that when id-ad-ocsp OID is not used, there is no
such statement by the issuing CA.

Further, look at 6.3.3, with respect to CRLs, for which processing begins
with
>   For each distribution point (DP) in the certificate's CRL
>   distribution points extension, for each corresponding CRL in the
>   local CRL cache, while ((reasons_mask is not all-reasons) and
>   (cert_status is UNREVOKED)) perform the following

That is, the stated processed CRLs are those that are matched to the
crlDistributionPoints extension (compared to, say, the CRL attribute on the
CA entry within the X.500 Directory).

This is the "standard" algorithm, which then concludes with:
>   If the revocation status has not been determined, repeat the process
>   above with any available CRLs not specified in a distribution point
>   but issued by the certificate issuer.  For the processing of such a
>   CRL, assume a DP with both the reasons and the cRLIssuer fields
>   omitted and a distribution point name of the certificate issuer.

However, the "any available CRLs" is not part of the standard, it is
effectively determined by local policy, which has repeatedly been my point.

Although RFC 6960 does not describe an explicit processing model, it is
designed to provide equivalent semantics as the CRL within this observable
state machine. Further, RFC 6960, Section 2.2, acknowledges that there are
three possible responders:
1) The CA that issued the certificate
2) A CA Authorized responder directly issued by the CA
3) Or... a "Trusted Responder" whose public key is trusted by the requester
(aka local policy)

In the absence of the extension with respect to RFC 5280 4.2.2.1, any use
of a responder, whether the CA's responder or a locally-configured Trusted
Responder, is entirely determined by local policy. You described one such
local policy implementation: a mapping between CA DN to URI.

However, I'm not aware of any requirement in the relevant specifications
that require a "single" OCSP URL for a CA DN. The requirement is merely
that a service listed in the certificate should be able to respond about
that certificate. That is, just like a CA can segment CRLs, there's nothing
intrinsic that prevents a CA from segmenting OCSP responders (e.g. serials
0-50 go to http://foo.example and serials 51-100 go to http://bar.example),
and the algorithms still hold out.

So, again I say, any issue resulting from always checking a particular
responder, even in the absence of an affirmative declaration by the CA, is
an issue driven by local policy, and thus can equally be solved by local
policy.

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 19 Nov 2020 09:52:36 +0100

I agree with the nay sayers.

I don't see enough benefits that outweigh the complications introduced
by adding such an extension.

I am not aware of any real use cases or client implemntations where
revocation checking is an issue today, that would be helped by such an
extension.

Best regards,
Tomas

On 2020-11-19 08:33, Ryan Sleevi wrote:
> 
> 
> On Thu, Nov 19, 2020 at 1:20 AM Salz, Rich <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     *>*There are, in effect, three possible sources for OCSP
>     information:____
> 
>     >1. The AIA of the certificate____
> 
>     >2. The Directory object associated with the DN of the certificate____
> 
>     >3. Local Policy____
> 
>     __ __
> 
>     >The absence of 1. is our first sign that the CA has decided not to
>     provide OCSP information____
> 
>     __ __
> 
>     I was not including you in the “some”  I was including you in the
>     question about where RFC 5280 says “not having AIA means there’s no
>     responder”  So please, tell me how you get to #1?  You often wrote
>     “in the context of RFC 5280 processing rules”  So please point me to
>     the rule?
> 
> 
> Judging by your reaction, I suspect you may have interpreted my
> statement to mean "If the CA has not provided an OCSP URL, it has
> authoritatively stated unambiguously it will not provide OCSP", which
> was certainly not the meaning I was trying to convey. Rather, it was
> meant to highlight that if the CA has not declared something in the
> certificate, then within the processing model of RFC 5280, the CA has
> not directed the client to do something, nor has it committed to the
> client that it will make something available.
> 
> The corollary of that is that when id-ad-ocsp OID is not used, there is
> no such statement by the issuing CA.
> 
> Further, look at 6.3.3, with respect to CRLs, for which processing
> begins with
> crlDistributionPoints extension (compared to, say, the CRL attribute on
> the CA entry within the X.500 Directory).
> 
> designed to provide equivalent semantics as the CRL within this
> observable state machine. Further, RFC 6960, Section 2.2, acknowledges
> that there are three possible responders:
> 3) Or... a "Trusted Responder" whose public key is trusted by the
> requester (aka local policy)
> 
> In the absence of the extension with respect to RFC 5280 4.2.2.1, any
> use of a responder, whether the CA's responder or a locally-configured
> Trusted Responder, is entirely determined by local policy. You described
> one such local policy implementation: a mapping between CA DN to URI.
> 
> that certificate. That is, just like a CA can segment CRLs, there's
> nothing intrinsic that prevents a CA from segmenting OCSP responders
> (e.g. serials 0-50 go to http://foo.example and serials 51-100 go to
> http://bar.example), and the algorithms still hold out.
> 
> responder, even in the absence of an affirmative declaration by the CA,
> is an issue driven by local policy, and thus can equally be solved by
> local policy.
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 19 Nov 2020 04:27:59 -0500

From: Spasm <[email-masked]> on behalf of "Salz, Rich" <rsalz=[email-masked]>
<snip> 

[CW] Also not sure who ‘some’ refers to, but my point was not that not having an AIA means there is no responder but that having an extension to explicitly tell me you don’t publish anything doesn’t mean anything at all to me if I elect to consider a cert revoked and that the provided definition leaves open to interpretation the meaning of the many certs in existence that lack AIA, CRL DP and the TBD extension. I still think that *if* there is to be a ‘positive statement’ it should be of the form “yes there is revocation info, but I am not telling you where it is in this cert”. It may be possible to fashion a statement of this sort as an AIA and spare creating a new extension to parse. Re-using AIA would take care of criticality semantics as well. Certs without new indicator, OCSP AIA or CRL DP would mean what they mean today – the CA has elected to not include a reference to revocation info source in the cert.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2020 09:49:17 +0000

*   [CW] Also not sure who ‘some’ refers to, but my point was not that not having an AIA means there is no responder but that having an extension to explicitly tell me you don’t publish anything doesn’t mean anything at all to me if I elect to consider a cert revoked and that the provided definition leaves open to interpretation the meaning of the many certs in existence that lack AIA, CRL DP and the TBD extension.

If a cert DOES have an OCSP AIA, are you still free to consider it revoked in your processing?  If so, why is the noRevAvail different?

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 19 Nov 2020 12:00:41 +0100

On 2020-11-19 10:49, Salz, Rich wrote:
>   * [CW] Also not sure who ‘some’ refers to, but my point was not that
>     not having an AIA means there is no responder but that having an
>     extension to explicitly tell me you don’t publish anything doesn’t
>     mean anything at all to me if I elect to consider a cert revoked and
>     that the provided definition leaves open to interpretation the
>     meaning of the many certs in existence that lack AIA, CRL DP and the
>     TBD extension.
> 
>  
> 
> If a cert DOES have an OCSP AIA, are you still free to consider it
> revoked in your processing?  If so, why is the noRevAvail different?

For sure you are very free. Hard-fail, soft-fail, interpretation of OCSP
UNKNOWN. Many discussions there have been on these variants.

OCSP AIA gives some valuable information for the processing logic. I
don't see how noRevAvail provides much valuable information.
I can imagine:
- don't check the local CRL cache
that may save a few CPU cycles, but that gain is small as there will be
no CRL, or CRL entries, in the CRL cache for this certificate

On the theoretical side:
Such an extension can give opportunity to some very bad practices. Such
as mixing issuance, from the same CA, of certificates which the CA keep
track of, with issuance of certificates that the CA does not keep track
of (we call such certificate throw away certificates). Issued under
different policies, I think best practice is to issue them from separate
Issuing CAs, in which case noRevAvail does not add any new information.
Encouraging mixing use cases where revocation is important with use
cases where revocation is not used seems like a potentially dangerous
practice.

Cheers,
Tomas

---

From: Carl Wallace <[email-masked]>
Date: Thu, 19 Nov 2020 06:26:17 -0500

From: "Salz, Rich" <[email-masked]>
Date: Thursday, November 19, 2020 at 4:49 AM
To: Carl Wallace <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension

[CW] Also not sure who ‘some’ refers to, but my point was not that not having an AIA means there is no responder but that having an extension to explicitly tell me you don’t publish anything doesn’t mean anything at all to me if I elect to consider a cert revoked and that the provided definition leaves open to interpretation the meaning of the many certs in existence that lack AIA, CRL DP and the TBD extension.

[CW] You wrote the words “MUST NOT use such information” so you would need to answer that one. Given you have elsewhere backed off that definition, i.e., “Maybe squint so much you can't even see the text, I admit” was after your “I prefer the language I first proposed“ with regards to criticality, I will wait for a new definition for the new extension semantics before commenting further other than to reiterate that I see no need for this extension but would prefer a statement that revocation info is available but no reference is provided if something must be defined towards this end.

---

From: Deb Cooley <[email-masked]>
Date: Thu, 19 Nov 2020 10:26:08 -0500

Wow.... Here is my vote (w/ some notes below).

1.  don't add a new extension (and definitely don't overload the
ocsp-nocheck extension).
2.  if one doesn't want to publish revocation information, then one should
merely not publish CRL DP and OSCP AIA (for whatever the correct language
is there)
3.  The systems that 'require' revocation checking are few and far
between.  I'm frankly surprised that DKG managed to find one. I know what I
would recommend to them, if they were to ask me for advice, which they
won't.  LOL.
4.  Making an extension critical is merely a recipe for disaster.  And
guess what?  The RPs don't pay one bit of attention.  I have examples of a
vendor happily using a key agreement cert for signature (KU is classically
marked as critical).  I can't even.

Notes:
A.  My employer has systems where we don't publish either CRL DP and OCSP
AIA, not because we don't produce revocation information, but because of
the latency it would add having a RP reach back through multiple networks
and boundaries to do that checking.  Instead we push those responses and
CRLs to locations that are easily reachable by the RP.  This allows us to
enable revocation checking w/out incurring a large latency issue.  Note:
the use cases here span authentication, document signing, email protection,
etc.

B.  I was slightly appalled at the idea that a stapled OCSP response would
be ignored if the server certificate didn't populate the OCSP AIA.  Maybe I
was more than slightly appalled.  Dunno.  Seems a bit silly.

C.  RFC5280 is a tiny bit long in the tooth.  The grand plans for how PKI
could be used have not come to pass (tell me one implementation that parses
and/or pays attention to certificate policies, I'll wait, making popcorn).
(1) The reality is that what most RPs see (people, sitting in their living
rooms, perhaps grandmas) don't want to have to know any of this, they just
want it to work.
(2) In the enterprise cases (mostly what I work on in my day job), if we
can do it under the covers, the RPs don't whine too much (that's a lie,
they whine, but we make them use it anyway unless they have lots of stars
and then we do it for them).
(3) In the cases where there aren't people for RPs, we still have human
developers.  And it is largely still done incorrectly.

D.  There is definitely a difference between Web PKI and anything else -
S/MIME, code signing, IPSec etc.  We should leave the Web PKI issues to the
CA/B Forum.

This is my longest post, probably ever.
Deb Cooley

On Thu, Nov 19, 2020 at 6:26 AM Carl Wallace <[email-masked]>
wrote:

>
>
> *From: *"Salz, Rich" <[email-masked]>
> *Date: *Thursday, November 19, 2020 at 4:49 AM
> *To: *Carl Wallace <[email-masked]>
> *Cc: *LAMPS <[email-masked]>
> *Subject: *Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension
>
>
>
>    - [CW] Also not sure who ‘some’ refers to, but my point was not that
>    not having an AIA means there is no responder but that having an extension
>    to explicitly tell me you don’t publish anything doesn’t mean anything at
>    all to me if I elect to consider a cert revoked and that the provided
>    definition leaves open to interpretation the meaning of the many certs in
>    existence that lack AIA, CRL DP and the TBD extension.
>
>
>
> If a cert DOES have an OCSP AIA, are you still free to consider it revoked
> in your processing?  If so, why is the noRevAvail different?
>
>
>
> [CW] You wrote the words “MUST NOT use such information” so you would need
> to answer that one. Given you have elsewhere backed off that definition,
> i.e., “Maybe squint so much you can't even see the text, I admit” was after
> your “I prefer the language I first proposed“ with regards to
> criticality, I will wait for a new definition for the new extension
> semantics before commenting further other than to reiterate that I see no
> need for this extension but would prefer a statement that revocation info
> is available but no reference is provided if something must be defined
> towards this end.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Nov 2020 19:32:17 +0000

I don’t want to make Deb write long notes any more, so

> 2.  if one doesn't want to publish revocation information, then one should merely not publish CRL DP and OSCP AIA (for whatever the correct language is there)

I will make sure we can live with that.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Nov 2020 12:34:36 -0500

> All of them?  I couldn't figure out how to say "and not a CA".

yeah, i think all of them -- the e_sub_ca_aia_does_not_contain_ocsp_url
label only triggers on intermediate CA certificates:

https://github.com/zmap/zlint/blob/3f689d276c06aad066b36967c4af3f75f6822247/v2/lints/cabf_br/lint_sub_ca_aia_does_not_contain_ocsp_url.go

says:

    func (l *subCaOcspUrl) CheckApplies(c *x509.Certificate) bool {
	return util.IsCACert(c) && !util.IsRootCA(c)
    }

Note that this requirement is no longer strict in the Baseline
Requirements, given ballot SC31:
https://github.com/zmap/zlint/issues/462

But anyway, this doesn't demonstrate a need for either id-ce-noRevAvail
or ocsp-nocheck, right?

 --dkg