Re: [netconf] Paul Wouters' Discuss on draft-ietf-netconf-crypto-types-29: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

That is different from our usage of crl-strict=yes

For us (libreswan) strict means:
- If CRL is expired, block everyone
- If OCSP not available, block attempt

non-strict means:
- if CRL expired, but cert is in CRL, still reject. But if it is not in
CRL, allow it
- if OCSP not cached and fails, still allow client

But if the cert itself is invalid, we never allow it.

I'm not sure if we would need to add this. I'm fine either way. Perhaps
chat with the WG, or don't add it now?

Paul

On Mon, Feb 12, 2024 at 2:45 PM Kent Watsen <[e-mail]> wrote:

> Hi Paul,
>
> On Feb 11, 2024, at 9:37 PM, Paul Wouters <[e-mail]> wrote:
>
> I have no good advice to give on strictness of CRLs and OCSP. Obviously a
> per connection setting would be better than a global setting but that might
> not be easy. Eg libreswan has it as global option partially because it
> keeps a global store of received certificates.
>
>
> Granular is better.
>
> I’m thinking to add the following to the `trust-anchor-cert-grouping` and
> `end-entity-cert-grouping` groupings:
>
>     leaf disable-stict-enforcement {
>         nacm:default-deny-all;
>         type boolean;
>         default false;
>         description
>           "Disables strict enforcement of this certificate.
>            Ignore issues regarding, e.g., the certificate's
>            validity period or CRL/OCSP validity.
>
>            This flag should only be set in an emergency
>            to enable a service to work.  Setting this flag
>            Is NOT RECOMMENDED.”;
>
>
> Is this what you want?
>
>
>
>
> Paul
>
>
>
> Kent
>
>
>