Re: [lamps] Warren Kumari's Block on charter-ietf-lamps-02-00: (with BLOCK and COMMENT)

On Wed, May 23, 2018 at 1:10 PM, Warren Kumari <warren@kumari.net> wrote:

> Warren Kumari has entered the following ballot position for
> charter-ietf-lamps-02-00: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lamps/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> "3.
> 
> 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 them pointless."
>
> This makes me twitch -- how short is "short"? And how long is the time to
> "detect, report, and distribute revocation information"? With e.g: CT,
> misissued certificates may be visible before they are used in an attack,
> decreasing the detection time.
>

How about 
"

Specify the use of "short-lived" X.509 certificates that are issued with
validity intervals that fall within the validity window for reporting
revocation
information permitted by the application, thus obviating the need for
online certificate status reporting"

Note:

* Yeah, 'obviating', sorry but it does not necessarily eliminate the OCSP
requirement for legacy reasons but it makes using the service pointless.

* Such certificates may still be listed in CRLs but the treatment of these
is likely to be different.

* At least one browser provider still believes in certificate revocation
and is looking to support short lived certificates as part of a strategy
that provides for much more aggressive revocation than is currently
possible. That is within minutes rather than days. So this is not really
about killing revocation, it is about superseding OCSP.

> Also, I would figure that it is still useful to know that a certificate was
> revoked and didn't just expire -- if I see a certificate which expired 10
> minutes ago I may be willing (after some consideration, checking my clock,
> etc)
> to decide to trust it anyway (even if that's a bad idea!), but a revoked
> certificate is a clear indication that something bad happened, and changes
> my
> risk assessment.
>
> It's entirely possible that there is a really good reason why I'm wrong /
> that
> this argument doesn't make sense in some use cases (or just that I'm nuts!)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Also, "revoking them pointless" does not parse - perhaps "revoking them is
> pointless"?
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>