Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt

Richard Barnes <rbarnes@bbn.com> Tue, 11 September 2012 03:43 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7821F875B for <atoca@ietfa.amsl.com>; Mon, 10 Sep 2012 20:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAhsQLhpNYle for <atoca@ietfa.amsl.com>; Mon, 10 Sep 2012 20:43:23 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D783F21F875A for <atoca@ietf.org>; Mon, 10 Sep 2012 20:43:22 -0700 (PDT)
Received: from [128.89.255.41] (port=56562) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1TBHNi-0009dG-2J for atoca@ietf.org; Mon, 10 Sep 2012 23:43:22 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1278)
From: Richard Barnes <rbarnes@bbn.com>
In-Reply-To: <20120911033801.16598.18619.idtracker@ietfa.amsl.com>
Date: Mon, 10 Sep 2012 23:43:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com>
References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com>
To: atoca@ietf.org
X-Mailer: Apple Mail (2.1278)
Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt
X-BeenThere: atoca@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2012 03:43:23 -0000

Dear ATOCA,

In order to respond to the chairs' call for candidate alert format documents, we have put together a revision of draft-barnes-atoca-escape.  As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a CAP document, in order to add authentication for alert originators (digital signature and "alert token").  

The changes from -00 are largely to add more explanatory text, and clarify a few things technically. We haven't translated the whole thing to JOSE (yet).  Mostly, our hope is that in reading the new version, you'll be able to envision how these secure alerts can be used to build an overall alerting system.  For example, they highlight some of the things that a discover / metadata protocol might need to provide (e.g., public keys for authorities).

Comments very welcome.  There's even a list of open questions at the front!

Thanks a lot,
--Richard



On Sep 10, 2012, at 11:38 PM, internet-drafts@ietf.org wrote:

> 
> A new version of I-D, draft-barnes-atoca-escape-01.txt
> has been successfully submitted by Richard Barnes and posted to the
> IETF repository.
> 
> Filename:	 draft-barnes-atoca-escape
> Revision:	 01
> Title:		 Encoding of Secure Common Alert Protocol Entities (ESCAPE)
> Creation date:	 2012-09-11
> WG ID:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-barnes-atoca-escape
> Htmlized:        http://tools.ietf.org/html/draft-barnes-atoca-escape-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-barnes-atoca-escape-01
> 
> Abstract:
>   Recipients of emergency alerts need to be able to verify that an
>   alert they receive was issued by an authorized source.  The Common
>   Alerting Protocol (CAP) provides a standard way of encoding alert
>   information, but does not provide any security features that would
>   support authentication of alert originators.  This document describes
>   a security wrapper for Common Alerting Protocol objects to allow
>   alerts to be signed by alert originators.
> 
>   Please send feedback to the atoca@ietf.org mailing list.
> 
> 
> 
> 
> The IETF Secretariat
>