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

Richard Barnes <> Wed, 15 March 2017 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C908312E858 for <>; Wed, 15 Mar 2017 16:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vwpybxe56ay2 for <>; Wed, 15 Mar 2017 16:37:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB27C12E852 for <>; Wed, 15 Mar 2017 16:37:43 -0700 (PDT)
Received: by with SMTP id g10so21105341wrg.2 for <>; Wed, 15 Mar 2017 16:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTivnJycpg4XNY87PUpK+VE374ldA4PlwkH471V/1zA=; b=ZpqRwkhkc4DFGZ83woi2skSW1rh6a3pxSoqMtfW+0LdDfgzEQvuoA7GHxFB4/hh7T1 hOQ7T+rxL7bFBwk70Gzg0dqB/uFFB4aYSdGueJYeGWkIR/2g1epsJ7WRCMRX51sXNSkK nvZnaWKZYF/JqprrwRwpj/obwlaKOtCbwGHE59jJmG/iGmr6rgxE6dplzKO+kfOMezET Z5yhvXWMGeUV2knlzKUbzsmjhyWo08Y1/vme0CF9JQDO5SdgiGhYstubGrf6l5zaY86W vHipqm5f34/UjowZIFlUU7aHunyxXq8YP+U/RtTkssZRM3ETx/hZHzwJN+R8AinJE3PM WFsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTivnJycpg4XNY87PUpK+VE374ldA4PlwkH471V/1zA=; b=FGvtUHHHAK144sxeMvEqutfK2ziQDxBcoHzgZto+GAyJRDCCA7LCy85JxTMGR2UmM2 NmNzic0hDdFXKwD5bMGrC/XgJ4n1RSenLFPpbr2DCwP73kDaYs4MnQ+EUH88e7YbpQ+f fWF43Qfh0XkQRnDusfeje0/J9rFH13+RgMLlaXDVy47Cbm0af4rtOQbOseVk3+jVQaxx fAG7a3IUfS5vpV/wlGGGk9BHX7I68Lca1dcjuMhph682OaKKLZPWUEZ2axnwlSPX3RNi mmal6w8heI/PZ+5dOpbZTy4E4tRAt5T9LrRL8dDGhZhMtoTVth25RNmM0DpiCqxH2ZZe XAfg==
X-Gm-Message-State: AFeK/H0o40UfuYq9BWhB/TptqQVYqcg4VabgKNMoBLccNUPmNSGJNVJ7keQsFwmsPg6Aqrtc/7IsSghlH42Fiw==
X-Received: by with SMTP id s2mr5684867wra.149.1489621062101; Wed, 15 Mar 2017 16:37:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 15 Mar 2017 16:37:41 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Barnes <>
Date: Wed, 15 Mar 2017 19:37:41 -0400
Message-ID: <>
To: "Peterson, Jon" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="f403045ea68841c0a3054acd6e3e"
Archived-At: <>
Subject: Re: [stir] certificates: short-lived or status
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Mar 2017 23:37:47 -0000

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.


On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <>

> 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:
> 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:
> ... 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