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

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Aug 2012 11:34:57 -0700

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.

A submission made earlier than this date will give us more time to
discuss it.  That is good if we are to meet our later milestones for
adoption and publication.

---

From: Matt Lepinski <[email-masked]>
Date: Fri, 17 Aug 2012 14:50:30 -0400

This sounds like a good path forward.

I believe that draft-barnes-atoca-escape-00 is a very rough first cut at 
a secure transport/delivery agnostic mechanism for authenticating 
CAP-formatted alerts.

Note that draft-barnes-atoca-escape-00 has a section devoted to open 
questions. If you have an answer to any of these questions, or 
additional questions not considered in the draft please send mail to the 
list. Also, if this is totally the wrong approach for authenticating CAP 
alerts, please send mail to the list.

- Matt Lepinski

On 8/17/2012 2:34 PM, Martin Thomson wrote:
> _______________________________________________
> atoca mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atoca
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Aug 2012 13:06:15 -0600

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 
> 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/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 17 Aug 2012 17:16:07 -0400

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
> 
> -----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-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Aug 2012 15:44:14 -0600

On 8/17/12 3:16 PM, Richard L. Barnes wrote:
> 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...)

Yes, that all makes sense. My apologies if I missed earlier discussion
on this topic.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Aug 2012 15:12:02 -0700

> 2. Define a way to transport those over XMPP (XEP-0127-bis)

And we are doing 1, just 1.

If this succeeds, we can talk about doing 2, or something else.

I should also point out that CAP does specify a signing capability
based on XMLDsig.  One potential outcome is that a profile of XMLDsig
is developed that can be used in this context.  Based on what I know
of XMLDsig, that seems unlikely, but this is ultimately a decision for
the working group.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 17 Aug 2012 18:20:16 -0400

> If this succeeds, we can talk about doing 2, or something else.

Yep, that's what I meant.  Just outlining the broader MO.

> of XMLDsig, that seems unlikely, but this is ultimately a decision for

Do you know if any of the real CAP implementations out there use this mechanism?