[POSH] Delegation duration

Michael Procter <michael@voip.co.uk> Tue, 17 September 2013 12:46 UTC

Return-Path: <michael@voip.co.uk>
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 1425B11E8434 for <posh@ietfa.amsl.com>; Tue, 17 Sep 2013 05:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 ezXxIZhv2C-I for <posh@ietfa.amsl.com>; Tue, 17 Sep 2013 05:46:24 -0700 (PDT)
Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with SMTP id B55B111E8418 for <posh@ietf.org>; Tue, 17 Sep 2013 05:46:12 -0700 (PDT)
Received: from mail-wi0-f170.google.com ([209.85.212.170]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKUjhPDsWzab3V2alDv/BExeKQvxhxuFm+@postini.com; Tue, 17 Sep 2013 05:46:12 PDT
Received: by mail-wi0-f170.google.com with SMTP id cb5so4942042wib.3 for <posh@ietf.org>; Tue, 17 Sep 2013 05:46:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=S0OfXSwGUXPK3ND01SMfG2//vVYKnxE3oDcKbGbnY0M=; b=Z8jx1rMZdW3coBwFAaCQGW9AO6YAmDbQT6uGxfCJlRXJBgP4omB/cD5ciWpDba5jQ+ uromV0lGsmzTRAoxktJY1gNkngeEyTnlnu4cMCFEKUUeq6NleMDNBxqu15+9i9vkxs2v U8Z9DwFc9vUazgjj5k9A3GArn2pTBcD0tddUwybytur+CIWSHs5K5brzwnZLxalWV3Im +7qLU8u+jJPqoJ3qLxzu+Z0vYDrxFB9wrnrNkv4oUyEjQGhjJODh8oEsQeyIL7PHMwYx OizolYJkuVtlEHIF6gFE9syti7j0Ln0XHNYOHeUwphaUC89vdXQodmDPnCvMcmFEJVBO UNVA==
X-Gm-Message-State: ALoCoQl6dKmuz9pJ8wXnjSyCtGus2mhpKmCHt1nVbTK7Shah/eJObIoAvhWLi/o8B2bZfJE30cQejFHmUCdLFklLB4orih8BPd0DnDxcxZvZHtD1TjV2LPj3c2RJvC5Gqq+9VIsjOy0rCyy+VB7nI8A1vZS1sKLvdA==
X-Received: by 10.180.182.68 with SMTP id ec4mr2384699wic.40.1379421960864; Tue, 17 Sep 2013 05:46:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.182.68 with SMTP id ec4mr2384695wic.40.1379421960797; Tue, 17 Sep 2013 05:46:00 -0700 (PDT)
Received: by 10.194.93.34 with HTTP; Tue, 17 Sep 2013 05:46:00 -0700 (PDT)
Date: Tue, 17 Sep 2013 13:46:00 +0100
Message-ID: <CAPms+wSp-DZgP_iGfHbdZUmVFhu7LLMHmR6+36udEPV2m9BzVA@mail.gmail.com>
From: Michael Procter <michael@voip.co.uk>
To: posh@ietf.org
Content-Type: multipart/alternative; boundary="047d7b66f599f8147304e693b3de"
Subject: [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 12:46:42 -0000

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.

Regards,

Michael