IETF Logo Mail Archive

Re: [Acme] ACME signature mechanics

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 17 December 2014 17:02 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0E1A900B for <acme@ietfa.amsl.com>; Wed, 17 Dec 2014 09:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-5tKngsN7au for <acme@ietfa.amsl.com>; Wed, 17 Dec 2014 09:02:39 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E441A9028 for <acme@ietf.org>; Wed, 17 Dec 2014 09:02:12 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id u10so12778974lbd.20 for <acme@ietf.org>; Wed, 17 Dec 2014 09:02:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IbKR9gQPswvC6AaRMM+3MhPOZQPK1Udcix1Xkfa2z+0=; b=0EHm6XS35PYzyOgNI74UPBb0Hjub3W32ljKZPqKWSSSsGKghTNS/as2EXMyd3CdnFm GzBSZs56qQx697SKKUKoNn5OT4OUHJr/2H+UjpIv4iOU38PI9aTMO3z/5Ht7bxwH+/ip hZZuh+HTmujEkrvIqGsweQA3AEy/k6spCtwgZxgWchDEINqx70Cf13H5CSbKyLE+zWwV 6iSYiE04uSr+4i9W3NCnOJh5cjLXB9ZiQNKo5Y+9fgt8ZqQTTHO6ZuNvIrmCxCpYbPPJ svoBN+RVDB35s4m0qNVgKz367a2MgIh622YMmC53IDy+rsLoRL5pLLE7MWezAn49ucF+ t+BA==
MIME-Version: 1.0
X-Received: by 10.152.8.225 with SMTP id u1mr40093360laa.21.1418835730925; Wed, 17 Dec 2014 09:02:10 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.19.42 with HTTP; Wed, 17 Dec 2014 09:02:10 -0800 (PST)
In-Reply-To: <CAL02cgT9iYqtX2Ui5XQYnj=yeF_QnSkKn-jE0D5d56WMzB5bBg@mail.gmail.com>
References: <548FF9E3.1020703@gmail.com> <CAL02cgT9iYqtX2Ui5XQYnj=yeF_QnSkKn-jE0D5d56WMzB5bBg@mail.gmail.com>
Date: Wed, 17 Dec 2014 12:02:10 -0500
X-Google-Sender-Auth: Joc-ekOMxqJahzcW_GpF3_93C3E
Message-ID: <CAMm+LwjwG0dPTkByu5WZ_ev3xNxAMwunoc-A_VK4sKPSZXRYDw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary="089e0158b79ebc8ea0050a6c6f93"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/LYzeVYSZ5tS6CxjbQ-b9Ynt-1uU
Cc: "acme@ietf.org" <acme@ietf.org>, Anders Rundgren <anders.rundgren.net@gmail.com>
Subject: Re: [Acme] ACME signature mechanics
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Dec 2014 17:02:41 -0000

On Tue, Dec 16, 2014 at 11:27 AM, Richard Barnes <rlb@ipv.sx> wrote:
>
> I think there might be a middle way here.  I've been musing about making a
> "Content-Signature" header that just carries a JWS signature over the
> payload (no HTTP headers).  Since HTTP has to carry the payload bit-exact,
> there's no c14n nonsense, so this could be much simpler than other HTTP
> signing proposals.  It's sort of like JCS, except that there is actually a
> guarantee that the payload stays the same ;)
>
> That said, if your concern is really human readability, I don't think it's
> a tragedy to make someone copy/paste into a base64 decoder.
>

I do. If we are going to write protocols that can't be easily interpreted
in wireline form then why not go binary with JSON-B, CBOR or what have you.

I like the idea of using a header like container for the signature. It
makes good architectural sense and it is easy to code. A signature is
logically meta-data and so it should be expressed as a header.

I don't see any value in the 'protected' or 'header' slots. They just
confuse the issue. We should have ONE JSON blob that has all the data that
we need and sigh that. All the data that is the case shall be signed and
any data that is not signed shall be ignored.

So the running example would be written thus:


Signature: alg=RS256; nonce=h5aYpWVkq-xlJh6cpR-3cw;
sig=KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ; KeyID=???TBS

 { "certificateRequest" : {
     "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
  }  }

The "certificateRequest" object contains exactly the sequence of octets
that is signed. No moving bits round, no splicing, no complications at all.
What is in the signature scope and what is not is clear and unambiguous.

The only objection I can see to this approach is that it makes JOSE pretty
much redundant.


That does leave two open issues to be decided though:

1 Should the signature header be part of the HTTP header or the payload?
2 How to encode the KeyID?


I have a marginal preference for making the signature header part of the
HTTP header because that is how most Web servers and support libraries are
designed to work. They make it really easy to pull data out of a header. On
many platforms the RFC822 tag value pairs are automatically mapped to
corresponding data structures.

There is an argument for making the signature part of the payload though.
It is not a HTTP protocol header, it is content metadata and these should
have always been kept separate.


The second one is a little bit more subtle as we definitely need a way to
identify which key is used and I don't like the way it is done in the
example because we end up specifying the key twice and relying on some
party to check they are the same. There lies the path to tears, weeping and
gnashing of teeth.

I would rather make the KeyID implicit in the case and require the
application to ferret it out from whatever CSR type object it is using. It
would be perfectly OK in my view to define a parallel JSON structure to
allow an all-JSON certificate issue path as an alternative to PKCS#10. It
would also be OK to use a combination of both to allow additional
information to be provided. But presenting security critical information
through redundant paths without a means of forcing cross checking is a bad
plan.

v2.23.0 | Report a Bug | By Email