Re: [stir] certificates: short-lived or status

I would note that "freshness" is but one aspect of a certificate that you
need OCSP for.  The far more common use in the WebPKI is when the CA simply
screws up.

In any case, to recap the experience from the Web PKI, the trade-off space
has basically the following shape:

1. Do a live query [draft-ietf-stir-certificates-ocsp]
2. Make something with a short lifetime
2.a. Mandatory OCSP stapling
2.b. Short-lived certificates [draft-peterson-stir-certificates-shortlived]

The trade-off is basically between the sender/signer having to do queries
(to refresh OCSP or get a new cert) and recipient/verifier having to do
queries (to fetch OCSP).  (2.a) is a bad deal unless you have some legacy
need to use OCSP; otherwise it's just bloat relative to (2.b).

If you ask web people, you're likely to get a pretty strong preference for
(2), i.e., putting the burden on the sender, because (a) it's more
predictable and (b) it's offline with respect to call time, and thus much
less performance sensitive.  The web started out with (1) and it has turned
out to be totally unworkable, because the CAs can't operate OCSP servers
that are good enough to avoid seriously degrading the performance of
browsing experience.

The main push-back we get from server operators about (2) is that it
requires outbound connections from web servers -- load and downtime never
come up as issues.  Outbound connections shouldn't be an issue for STIR
signers, since they're likely to be making outbound connections all the
time anyway.  Even if not, it's a simple firewall rule to write to let out
connections to your CA.

--Richard

On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <jon.peterson@neustar.biz>
wrote:

>
> In reaction to the IESG review, and as well, to our own general sense that
> we're still not ready to mandate any particular direction, we ended up
> pulling the real-time status check of OCSP out of the last version of
> stir-certificates. Figuring out how we want to manage certificate
> freshness, especially in light of certificates assigned to telephone
> numbers, is probably the last bit about the core STIR work, before we go on
> to extensions and so forth, that we need to tackle.
>
> I'd like to spend some meeting time talking about two approaches, as well
> as any better ideas anybody comes up with for this. The first is roughly
> what was in the stir-certificates document previously, which is now
> captured in:
>
> https://tools.ietf.org/html/draft-ietf-stir-certificates-ocsp-00
>
> The other is an approach based on short-lived certificates, which would
> likely rely on ACME or something similar. I've mocked up a discussion draft
> for that:
>
> https://tools.ietf.org/html/draft-peterson-stir-certificates-shortlived-00
>
> ... though it is still fairly content-free at the moment.
>
> I think reviewing what we've done with stir-certs and these two approaches
> warrants some face-time discussion. Thoughts here on the list beforehand
> are welcome too.
>
> Thanks,
>
> Jon Peterson
> Neustar, Inc.
>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>