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

Martin Thomson <martin.thomson@gmail.com> Wed, 12 September 2012 17:02 UTC

Return-Path: <martin.thomson@gmail.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 8861E21F861B for <atoca@ietfa.amsl.com>; Wed, 12 Sep 2012 10:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level:
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 Vv82Oq-MV0F2 for <atoca@ietfa.amsl.com>; Wed, 12 Sep 2012 10:02:50 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7FF521F853F for <atoca@ietf.org>; Wed, 12 Sep 2012 10:02:49 -0700 (PDT)
Received: by lbky2 with SMTP id y2so1427704lbk.31 for <atoca@ietf.org>; Wed, 12 Sep 2012 10:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CgGhNXqxpXKeH8MI/T8FeMasdKJbdb+w42YmmsEBRdw=; b=AKNUhq679Htz4q/4hRV0Zcd+4DM7C1Ml/pI5KzPzZka8DY6fziZXXU5yRlXF6QXetC zLX6JbLq4FZ67T80ad4rxDGtsTZ0qCM5EWZeTnPx8G0Xn7ClVe6JwlF2ulm5jtPSVNQY UdmHkt6tLmY7S9cpDl9wPZf5XBXWqcJbz3wagX4Z0D7HvKEtkLoQQFeCImDoqokR8E+e 97ktMI4HMmDMzH59/Z/8tZEol/rJDDhX2L8N90Z/gYusbzJVPz8eQFA31mcrBeiB2oAm 2bcOhUqqaheB5G41zURCxfgqt4yjyZADG7hAL9IYXihXs8A3nXTrzOTJIsaYEtVTMzrg MdYg==
MIME-Version: 1.0
Received: by 10.152.123.140 with SMTP id ma12mr19756506lab.22.1347469368582; Wed, 12 Sep 2012 10:02:48 -0700 (PDT)
Received: by 10.112.1.36 with HTTP; Wed, 12 Sep 2012 10:02:48 -0700 (PDT)
In-Reply-To: <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com>
References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <CABkgnnWGN-GhVzx=0+Ch_H173=g7m2V43KqEtjRMm33LcZBRJw@mail.gmail.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com>
Date: Wed, 12 Sep 2012 10:02:48 -0700
Message-ID: <CABkgnnVJBzn=GQ=VB8w_+zBuuyAbKPsb4cQUP-EM19-ne8AAcg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Art Botterell <acb@incident.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: atoca@ietf.org
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: Wed, 12 Sep 2012 17:02:50 -0000

On 11 September 2012 12:36, Art Botterell <acb@incident.com> wrote:
> 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?

That's precisely the problem.  I can digitally sign a serialization of
XML relatively trivially, but to truly sign the XML then you need to
canonicalize the content.  JOSE are dealing with signing in a
completely different fashion for this exact reason: they only deal
with the serialization.  That simplifies implementation greatly.

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

Perhaps they have.  Though I note that it's a different matter to
implement this sort of canonicalization in millions of devices with a
wide range of capabilities.  Last I checked, XML canonicalization
libraries weren't small either.

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

Checking a signature is expensive.  Proving that you have access to
the pre-image for a prearranged hash allows clients to filter out
bogus alerts quickly.