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

[Art Botterell <[e-mail]>]

Hi Martin -

Not sure how one might implement digital signatures of XML without canonicalization, really, but if that "accepted wisdom" is correct, wouldn't that better be addressed by refinement or replacement of RFC3275 rather than vectoring off into development of a "splinter" specification?

I do observe that all the various implementers of IPAWS-compatible systems in the US have had to implement XML signatures and seem to have managed without undue difficulty.  Perhaps the available libraries have improved.

And I'm not clear on what it is that tokens would optimize, but hopefully Richard can explain that.

- Art


On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote:

> Art,
> 
> It is generally accepted wisdom (in the IETF at least) that XML DSig
> [RFC3275] is a recipe for interoperability failure.  The primary
> reason for this is the dependency on XML canonicalization.
> 
> I'd be interested in hearing a different perspective.  I've used the
> apache library to implement an enveloped signature and it wasn't
> straightforward.  I'm not aware of any other implementation, but it's
> been a few years since I last looked.
> 
> Of course, it's a different thing to say the mechanism is broken or
> unusable rather than "there is no mechanism".  The former statement
> requires greater justification.
> 
> I'll let Richard explain the token mechanism.  It's an optimization.
> 
> --Martin
> 
> On 10 September 2012 22:20, Art Botterell <[e-mail]> 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