Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

Sam Hartman <hartmans-ietf@mit.edu> Mon, 04 May 2015 17:32 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B91A86EF for <kitten@ietfa.amsl.com>; Mon, 4 May 2015 10:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 R8piXytD4Yl9 for <kitten@ietfa.amsl.com>; Mon, 4 May 2015 10:32:20 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DB31A86E8 for <kitten@ietf.org>; Mon, 4 May 2015 10:32:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AAD36206F7; Mon, 4 May 2015 13:31:10 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sln4mtnCPHbP; Mon, 4 May 2015 13:31:10 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 May 2015 13:31:10 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9594483168; Mon, 4 May 2015 13:32:17 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <alpine.GSO.1.10.1503111348200.3953@multics.mit.edu> <alpine.GSO.1.10.1503111405000.3953@multics.mit.edu> <5500AD51.5030902@mit.edu> <alpine.GSO.1.10.1503111725490.3953@multics.mit.edu> <BL2PR03MB2124E0360819B3162C9E48DD0060@BL2PR03MB212.namprd03.prod.outlook.com> <tsl38590yn0.fsf@mit.edu> <BL2PR03MB2127227DDC7941010BC26A6D0070@BL2PR03MB212.namprd03.prod.outlook.com> <550339DA.6000109@mit.edu> <BL2PR03MB21281E5DBF9A38B16C91338D0E90@BL2PR03MB212.namprd03.prod.outlook.com> <alpine.GSO.1.10.1504291620270.22210@multics.mit.edu> <tslbni0y0d2.fsf@mit.edu> <55478C61.2040601@mit.edu>
Date: Mon, 04 May 2015 13:32:17 -0400
In-Reply-To: <55478C61.2040601@mit.edu> (Greg Hudson's message of "Mon, 04 May 2015 11:12:33 -0400")
Message-ID: <tsl4mnsuu3i.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/Y17XwrLiMcenTEWoTsF15jhjg0w>
Cc: "kitten@ietf.org" <kitten@ietf.org>, Michiko Short <michikos@microsoft.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2015 17:32:22 -0000

>>>>> "Greg" == Greg Hudson <ghudson@mit.edu> writes:

    Greg> On 05/04/2015 08:48 AM, Sam Hartman wrote:
    >> I think it is entirely reasonably to ask all clients to send a
    >> freshness request.

    Greg> I think it's a little unfortunate, but if it will make
    Greg> Microsoft's life easier, an few extra bytes in each AS request
    Greg> won't break the world.

Well, it is kind of what RFC 4120 anticipates you'll do whenever you
introduce a new option.