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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 15 March 2017 23:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB1A12EA6A for <stir@ietfa.amsl.com>; Wed, 15 Mar 2017 16:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXBoBJRFHOQG for <stir@ietfa.amsl.com>; Wed, 15 Mar 2017 16:48:44 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6729712E852 for <stir@ietf.org>; Wed, 15 Mar 2017 16:48:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6AAF6BE38; Wed, 15 Mar 2017 23:48:42 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Mo37rMsy8oh; Wed, 15 Mar 2017 23:48:41 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CCC90BE2E; Wed, 15 Mar 2017 23:48:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489621721; bh=yMx9igiKtjlzh7PDtdYpWOHHW5XoLOV0PoYvEX/OZoA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=zy1H63XwScMzOM1PNwJtbRcYmkdA+JaHREV0le1Gzfxi3KA1tF2liUcfbepCf6HIL IEthKx/cU2958RyNG3+R5K9LHv1HNPCNc0s27h4B4m8Pe1C5aL4aeXiC44KfQnIGbh jtMR0y8B8Sp55F4Izw8Eq3YioGK1hA9QEqQv0fOk=
To: Richard Barnes <rlb@ipv.sx>, "Peterson, Jon" <jon.peterson@neustar.biz>
References: <D45861BA.1C7D28%jon.peterson@neustar.biz> <CAL02cgTSCPywYAaDEgL6rdOWgguJ76kpN5HFNTqN=0ej1fX_Hw@mail.gmail.com>
Cc: "stir@ietf.org" <stir@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <3ee1c759-5fa1-859f-eee5-4a3f9a7aa530@cs.tcd.ie>
Date: Wed, 15 Mar 2017 23:48:39 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAL02cgTSCPywYAaDEgL6rdOWgguJ76kpN5HFNTqN=0ej1fX_Hw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="9UOVP3utuiPW3db1jPPagoHpPSTGV7tKh"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/De-G7CrKmBBpdhGRhLgHvzD9B_8>
Subject: Re: [stir] certificates: short-lived or status
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 23:48:46 -0000


On 15/03/17 23:37, Richard Barnes wrote:
> 
> 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.

(2) also helps for privacy reasons. (1) would mean the
callee sending a cleartext OCSP query containing the
callers number. (In some cases.)

And FWIW, I'm not sure how the trade-offs between (2a)
and (2b) would apply in the case of stir. (2a) would
be more bytes unless (2b) has one more intermediate CA
cert for some reason, but that could happen so the
trade-offs would need a bit of exploring. The RP may
also have an easier time with (2a) as it is maybe
easier to insist on a fresh stapled OCSP response than
it is to decide when a still-valid cert is too old.

S.