Re: [atoca] Call for submissions: Secure Alert Format

"Richard L. Barnes" <rbarnes@bbn.com> Fri, 17 August 2012 21:16 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 4742811E80E9 for <atoca@ietfa.amsl.com>; Fri, 17 Aug 2012 14:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.582
X-Spam-Level:
X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 De3weLi5F1Rl for <atoca@ietfa.amsl.com>; Fri, 17 Aug 2012 14:16:14 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38111E80D1 for <atoca@ietf.org>; Fri, 17 Aug 2012 14:16:14 -0700 (PDT)
Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:58844) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1T2Tto-000DLO-Gc; Fri, 17 Aug 2012 17:16:08 -0400
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <502E9627.4030008@stpeter.im>
Date: Fri, 17 Aug 2012 17:16:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <22E8EC45-F535-4304-8C80-B2E17F59902C@bbn.com>
References: <CABkgnnXaDp-3D4msWLXQo8WCxojqMLp04ZSLa2P8YfXrGCGzOA@mail.gmail.com> <502E9627.4030008@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1278)
Cc: atoca@ietf.org
Subject: Re: [atoca] Call for submissions: Secure Alert Format
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: Fri, 17 Aug 2012 21:16:15 -0000

Hey Peter,

Thanks for this observation.

I think we were thinking of things in kind of the other direction:
1. Define a general signed alert format
2. Define a way to transport those over XMPP (XEP-0127-bis)

This approach provides a more general functionality than sending CAP in secure XMPP (e.g., with an RFC 3923 signature).  The relationship is essentially the same as that between POSH and, say, attribute certificates over HTTP.  In one case, the signature is being provided by the protocol used to deliver the alert; in the  other, the signature is attached to the object itself.  In the interest of being delivery-agnostic, ISTM that the object-based approach is preferable.

It may also be pretty trivial to extend XEP-0127 to support the security we describe here.  For example, if we allow detached signatures (which seems like a good idea), you could keep the same syntax as XEP-0127 and just add an attribute/element to carry signature data. (As long as the serialization of the CAP can't change...)

Hope this helps,
--Richard


On Aug 17, 2012, at 3:06 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 8/17/12 12:34 PM, Martin Thomson wrote:
>> The ATOCA WG needs you.
>> 
>> It has been determined that providing a means of authenticating
>> alerts is critical to the working group.
>> 
>> Please submit internet drafts containing proposals that address
>> this problem before September 12.
>> 
>> Such a proposal must be able to carry CAP-formatted alerts in such
>> a way that the source(s) of the alert can be authenticated by 
>> recipients.  Attributing trust to that source is not necessarily 
>> within scope, nor is it necessary to describe a protocol or
>> delivery architecture.
> 
> Some years ago, the XMPP Standards Foundation defined a way to send
> CAP-formatted alerts over XMPP:
> 
> http://xmpp.org/extensions/xep-0127.html
> 
> XMPP also includes methods for signed messages (e.g., RFC 3923,
> although the XMPP WG is considering a more modern approach based on
> the output of the JOSE WG).
> 
> If signed XMPP messages containing CAP-formatted alerts might be of
> interest, I would be happy to write an I-D defining this approach in
> more detail.
> 
> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlAulicACgkQNL8k5A2w/vxKaACg+FtkpH/ocmY9B08BfvNXgFLZ
> YlEAoJiGG0s1B6nzHWIgVhSPBbvutfbZ
> =CK+1
> -----END PGP SIGNATURE-----
> _______________________________________________
> atoca mailing list
> atoca@ietf.org
> https://www.ietf.org/mailman/listinfo/atoca