[Acme] Attested CSRs

Anders Rundgren <anders.rundgren.net@gmail.com> Sun, 04 January 2015 08:12 UTC

Return-Path: <anders.rundgren.net@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 393571A7001 for <acme@ietfa.amsl.com>; Sun, 4 Jan 2015 00:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 TVZZXl4sSRCp for <acme@ietfa.amsl.com>; Sun, 4 Jan 2015 00:12:11 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FC21A7007 for <acme@ietf.org>; Sun, 4 Jan 2015 00:12:10 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id w62so6293297wes.41 for <acme@ietf.org>; Sun, 04 Jan 2015 00:12:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=j4l97fDAAbDBGyart+acSlYQwxPb6jUISAdm99rnJdM=; b=KPpAJyr6mr4E9ys1I3anjQLAvsfZJqoebhFJC1J+Ke2tkguN70Qo/xIvWG8YqXYoZk NvyCKcFPXx97Z1SRr4lBTF/LN4MsYPrj2vnLIp4QM5GEXDb5bPCtMMbN3vNmq+rzQmjD oW3GoLgjaa8gRL4iL6InoSrzGfZT6vPQx8AIuZkWqQKGEYMW0xbb/EhOsn9a410RIgG8 hjG0ceZ9X1lXjxCzvkD7MGUD9R/qxZWATfYxzzK7+D3POkV9ctpvMoOjWXxcJdBwibdM JiRsDZyORCJRfXPBejAJyYH4DO1XdN7m5biIa98E6FoVMTTV3ZcMw2JbJZu1ndxAJPQf nKFg==
X-Received: by 10.180.79.200 with SMTP id l8mr13546237wix.65.1420359129322; Sun, 04 Jan 2015 00:12:09 -0800 (PST)
Received: from [192.168.1.79] (48.194.130.77.rev.sfr.net. [77.130.194.48]) by mx.google.com with ESMTPSA id kn5sm70647952wjb.48.2015.01.04.00.12.08 for <acme@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 00:12:08 -0800 (PST)
Message-ID: <54A8F5D7.3070805@gmail.com>
Date: Sun, 04 Jan 2015 09:12:07 +0100
From: Anders Rundgren <anders.rundgren.net@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/alternative; boundary="------------010507030604070008000000"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/TfuLvOEIgXZTgSPSgREOjcxTGv0
Subject: [Acme] Attested CSRs
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: Sun, 04 Jan 2015 08:12:13 -0000

Hi ACMErs,
I just wanted to mention that key-attestation schemes represent an alternative to PKCS #10 (PoP).
As an example the FIDO/Google U2F-token builds on this concept.  In summary the advantages could be:

- HSM-secured attestation keys could vouch for slightly less secured web-server keys
- Alternative to backup secrets
- CSR independent of requested key usage (like ECDSA versus ECDH or ECDSA versus RSA_OAEP)
- True attestation (=keys can be proved to reside in secure storage) could be a requirement for certain certification levels although probably not for web-servers

The following mockup (here dressed in JCS notation), should give you an idea on how such a CSR could be architected:

{
   "@context": "https://letsencrypt.org/acme/v1",
   "@qualifier": "AttestedCSR",
   "domain": "example.com",
   "nonce": "yPdYDThBqWRuKoZ24sXLOcqyKFx7abbSp8DF11rv0mo",
   "dateTime": "2015-01-02T12:25:19Z",
   "keyAttestationAlgorithm": "ACME-KA1",
   "attestedKeys":
     [{
        "id": "Key.1",
        "keyAttestation": "niS9_Urs0sscTE2bUkjkE7WgIALnjRdaxCHhQ...s9RdobcnDmWfE_ZUb9rHUva2I_JnZY3q1JnAkXGW_6rhA5kxn32zBoR9SvL",
        "publicKey":
          {
            "type": "RSA",
            "n": "ld-uUL2csxx3hbGqN_Ix48wbIgcas2i42ujmW3D2ZtT8tmr...B7VnYF56h45CD3FPLAYR9ZFNlAWdgTQi5OUdSJvAwK1w",
            "e": "AQAB"
          }
      }],
   "attestationKey":
     {
       "certificatePath": [MIIETTCCAjWgAwIBAgIGAUoqo740MA0GCSqGSI...uREScyhb_49Dqaq-OypeSJSChtKT4UuQTcmz2cs9Zi90RyQ7UzWNrQjoLERGLkuetIw]
     },
   "signatureKeyAttestation": "NrZnvexftkY_NtGcrQf2RDKizybbgWKUm8...gDUXsWfeVoF5aoFbx8OXzlFhKd_BB91OGZADSkuBacptgWETjXHNC5NUQ78W",
   "signature":
     {
       "algorithm": "ES512",
       "publicKey":
         {
           "type": "EC",
           "curve": "P-521",
           "x": "AP_f3bqRvBAvtC2dATIxEsXZfc-THnnMTkjOcyILsW3AFGGEp1d9NOESbIuCUw3fwFvR0WltuROBMg9ouycegZQn",
           "y": "ABrvjyrr0v7VcehkYbiyPM-V7Wwy7OrLWaOLn1q2TPmpqdH-PybgkAUSbwHzMNXYQNe4og5PKgRsBJWoKrxcZZLt"
         },
       "value": "MIGHAkIB4jih8QzkJYZ4bKa_cuwtiVTIctq66QFhA5F6TNy...-8oDgaqYUjIpFYW8yP8yuZH9ODNI6n28w5ktUBsmRIk-ixiOjSV02R6A6W"
     }
}

The key attestation properties are created inside of the attesting unit since the only thing an attester (of this kind NB) can sign is is something it has created itself which in this case is limited to key-pairs.  That is, the CSR body is not signed by the attestation key, but by an ephemeral signature key which also is attested.  The attestation itself is a signature over the public key.   All keys can thus be securely derived to the supplied attestationKey.

Anders