Re: [POSH] Delegation duration
Peter Saint-Andre <stpeter@stpeter.im> Tue, 17 September 2013 21:25 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: posh@ietfa.amsl.com
Delivered-To: posh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8511E85B3 for <posh@ietfa.amsl.com>; Tue, 17 Sep 2013 14:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.965
X-Spam-Level:
X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVoHxyJ2pSp9 for <posh@ietfa.amsl.com>; Tue, 17 Sep 2013 14:25:28 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 70D1A11E85B1 for <posh@ietf.org>; Tue, 17 Sep 2013 14:25:28 -0700 (PDT)
Received: from sjc-vpn7-1265.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C6CD241694; Tue, 17 Sep 2013 15:30:15 -0600 (MDT)
Message-ID: <5238C8C5.1080706@stpeter.im>
Date: Tue, 17 Sep 2013 15:25:25 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
References: <CAPms+wSp-DZgP_iGfHbdZUmVFhu7LLMHmR6+36udEPV2m9BzVA@mail.gmail.com> <C9CCAD08-4A22-4A8F-83B2-443CCC2A408A@edvina.net> <BF7E36B9C495A6468E8EC573603ED9411EF0CE47@xmb-aln-x11.cisco.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411EF0CE47@xmb-aln-x11.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Michael Procter <michael@voip.co.uk>, "Olle E. Johansson" <oej@edvina.net>, "<posh@ietf.org>" <posh@ietf.org>
Subject: Re: [POSH] Delegation duration
X-BeenThere: posh@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion about PKIX Over Secure HTTP <posh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/posh>, <mailto:posh-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/posh>
List-Post: <mailto:posh@ietf.org>
List-Help: <mailto:posh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/posh>, <mailto:posh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Sep 2013 21:25:40 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/13 10:34 AM, Matt Miller (mamille2) wrote: > > On Sep 17, 2013, at 9:04 AM, "Olle E. Johansson" <oej@edvina.net> > wrote: > >> >> 17 sep 2013 kl. 14:46 skrev Michael Procter >> <michael@voip.co.uk>: >> >>> Thanks for issuing -01, which addresses some of my questions. >>> I'm still concerned about one area though. To repeat from an >>> earlier email: >>> >>>> In section [7], you state that ideally, caching of the >>>> certificate obtained via POSH should be based on the >>>> expiration time of the certificate. I think this might be a >>>> little too trusting, as it ties delegation validity to >>>> certificate expiry. If I trust hosting.example.net to host my >>>> service today, that doesn't mean I will continue to trust >>>> them until their certificate expires. HTTP cache-control >>>> headers might be a useful way of indicating a short term >>>> trust though. >>> >>> I think it would be useful to consider adding a "validity" >>> field somewhere, indicating either a duration (this delegation >>> valid for 24 hours) or an expiry (this delegation valid until >>> 17th Sep 2013). Whether this is done via cache-control >>> headers, or a new field in the jwk, or some other mechanism is >>> less important to me, so long as there is some way of >>> indicating how soon the delegation may be revoked. >>> >> Caching to expiry time is not acceptable. I do agree that we >> need to have a header to define a decent caching time. >> > > I can see value in a duration/TTL, as long as that duration is > short (IMO, at most 24 hours). It's fairly easy to maintain in > deployment, and provides the practical benefit we're looking for. > > I also think an absolute expires is a bad idea. Given that I think > we want very short durations, an absolute expires time means the > document needs to be continuously updated, which increases the > burden on deployments. Agreed on the foregoing. > I will confer with my co-author on this, but I think putting > something in the POSH document is the most pragmatic approach. Yes, as long as when you say "the POSH document" you mean the hosted JSON file, not the Internet-Draft. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOMjFAAoJEOoGpJErxa2pcoYP/3Y1G6DMJ1usZ/US7YFHryXQ IljbZDcNhmQxlDWQmgCsoU5P/5IWsDEkHveRk7apAmpFOx4rwnkvfssCIEbzooGw ughKi/CTYQzxU/8hcHC+UUa1PVq3/b9yBgJDiw3Flpfytv12Bb2YwI2HED1qef9A PHNOHUgxYSKoj7QJMKVjyLGAzi2Fb52w09asUim/WcDbOQdvOhHTkV8oMZK8V2Ce jNEdV9ILTyDfSky2jOTpTLGy7TN44kee7i6p81GbgVTYnkeQC3P1Ev2aEA0Fiee7 TrUAkH+Fb8mYUa92ZOJ7TsQYRjXleYwpHekb5dhR8yOf1GlnImlEHcgNMG7drrEg g/CMdmsRll1F61GrrjaYNaqiAZ0vN7xpuX/X7NoEnIhLQIF+j84oyUsccVq8p/gv L54M6QN/tprsqWlh7m2C67eMs/vdMQA1YrjVcGZZF64sJA0u29Oa81xEVh7PPW3X UHfg54gtsDXPsgXlUJs06UG2SgUpPMO8577wBkTxAiUDvOkSxXa8cOq2/cs7huEf NdLDwKD48RgcC9Plh0DJP7ULBJt/qBEoCW1Cc1OKF7MeaeKdQMPLqY6U/SqQzdZp KBjwUackBzSSLQZ8ZcET9QJ5jRoj5V/g/nqdnysZgFHoRdSmKcUa8kU+F3M0cyZz F74wN9KbtgBzjOAWSKoi =jHNS -----END PGP SIGNATURE-----
- [POSH] Delegation duration Michael Procter
- Re: [POSH] Delegation duration Olle E. Johansson
- Re: [POSH] Delegation duration Matt Miller (mamille2)
- Re: [POSH] Delegation duration Peter Saint-Andre