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