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

[Richard Barnes <[e-mail]>]

Hey Art,

I apologize for that line.  I had forgotten about the use of XML-DSig in CAP, probably because, as Martin notes, it's broadly viewed in the IETF as not very interoperable.

In general, it seems like we have a choice to make as to what security container we want to specify here:
-- XML-DSig
-- S/MIME / CMS
-- JOSE

We (the authors) chose to go with S/MIME because in our view it was simpler to implement than XML-DSig and more mature than JOSE.  As Martin noted, the simplicity compared to XML-DSig is largely due to the fact that S/MIME just signs the serialized octets, so that the signing layer doesn't need any knowledge of XML.  In the long run, I think JOSE is probably the way to go, because it's likely to be even easier to implement than S/MIME, but that's still developing.

Could you provide any data on how much actual implementation / usage of XML-DSig with CAP?  

Thanks,
--Richard



On Sep 11, 2012, at 1:20 AM, Art Botterell wrote:

> Hi Richard -
> 
> I'm confused by the claim that CAP "does not provide any security features that would support authentication of alert originators."  
> 
> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The <alert> element of a CAP Alert Message MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing," and makes reference to both <http://www.w3.org/TR/2002/REC-xmlDSig-core-20020212/ > and <http://www.ietf.org/rfc/rfc3275.txt>.  
> 
> Indeed, XMLSIG has been a feature of every CAP version since 1.0.  And if that's not enough, there's also the existing OASIS EDXL-DE wrapper specification.
> 
> So while I'm a huge supporter of an end-to-end approach to CAP authentication, on the face of it the ESCAPE draft seems duplicative and somewhat ill-informed.  Also I fear I'm missing the point of the added "alert token" mechanism, other than to add one more maintenance task that nobody is going to want to own.
> 
> But possibly you've just leapt ahead too far for me to follow in a single bound.  What am I missing here?
> 
> - Art
> 
> 
> On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote:
> 
>> 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, [e-mail] 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 [e-mail] mailing list.
>>> 
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> _______________________________________________
>> atoca mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/atoca
> 
> _______________________________________________
> atoca mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atoca