Re: [dane] draft-ietf-dane-smime

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 17 October 2014 15:04 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B551A014F for <dane@ietfa.amsl.com>; Fri, 17 Oct 2014 08:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
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 d5JLxPi3CSsS for <dane@ietfa.amsl.com>; Fri, 17 Oct 2014 08:04:51 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8DA1A01AA for <dane@ietf.org>; Fri, 17 Oct 2014 08:04:51 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 55B652AB2B5; Fri, 17 Oct 2014 15:04:49 +0000 (UTC)
Date: Fri, 17 Oct 2014 15:04:49 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141017150448.GV20066@mournblade.imrryr.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <E507FC56-947B-4A93-AA81-F0507D2FBC69@ogud.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/BvOZKV-1l8zxXkd7ARS8Na6RyKs
Subject: Re: [dane] draft-ietf-dane-smime
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Oct 2014 15:04:54 -0000

On Thu, Oct 16, 2014 at 05:17:49PM +0200, Jakob Schlyter wrote:

> > If  X@Y sends S/MIME signed message to  DANE WG on January 20th 2016. 
> > X@Y leaves Y on Feb 15th 2016. 
> > 
> > Is there any value in being able to validate the signature when a document
> > editor gets around to read the message March 15 2016 while updating the
> > document referenced in the email to meet the ID deadline for IETF-95  ?
> 
> You basically want to know if certificate C was valid at time T. A CRL
> might tell you when a certificate was revoked, whereas OCSP does not.
> Neither of the proposals discussed in this group so far would help you
> with that either.

Perhaps some of you have seen the recent comments by Jerry Leichter
on Perry's cryptography list in the thread about HP revoking their
software signing certificate.  The problem with revocation of
signing certificates for "data at rest" is rather deep.  We simply
don't have correct semantics for this at present.

Revocation that invalidates messages older than the revocation
event is rather sub-optimal.

With email, the MUA and/or mailstore should validate messages when
they first arrive, and record the validity of the signature at that
point.  With validity frozen at time of arrival, it is largely
sufficient to remove the ability of obsolete keys to sign new mail
and delist them as valid keys for receiving new encrypted mail.

> Paul and I advocate that SMIMEA will only tell you if a given certificate
> is valid in real time (or in the proximity of). Others say an explicit
> revoked flag would be useful.

I concur, subsequent revocation of already received and at the time
accepted as valid mail is too little too late.  It has in most
cases already been acted on (for better or for worse) at time of
arrival.

-- 
	Viktor.