[Acme] Clarification about Identifier Validation Challenges

Romain Fliedel <romain.fliedel@gmail.com> Mon, 27 July 2015 10:40 UTC

Return-Path: <romain.fliedel@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DABA11B29BD for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 03:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DZD2L8sVkrMA for <acme@ietfa.amsl.com>; Mon, 27 Jul 2015 03:40:44 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9111B2ABB for <acme@ietf.org>; Mon, 27 Jul 2015 03:40:44 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so134116006wib.1 for <acme@ietf.org>; Mon, 27 Jul 2015 03:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Xn1iNw4Rqc1H+EULU7A2RCUl7UtSl9hHv5Oy7ZNs7GA=; b=nlL+Z4g4MAlXLycYeho+pDKUjkQi269VEsMks1tCTFi+IyIFn1M9XNlGHZo5ZwSj6D bBe4drzLnjPvf8fTEVxL/sYszF75cFt8aSrAsB01b0eCo28CRp+p+mPMDIwLqyrhjIZI ktWI5DFMnLD+LwtOzRb2WlH8sm2Tz4A+Ot0lWNDTPywzRbX3wjeSRxMQ3LWA87a6360p RHhoZdk9XDlJC44QHrpIiGbEfXLiu2/e804TGqpJEV6t9/ajYX8IGIC/GKQ+d+pn6oIk JROCqv3Pc+0y2TgWEa83shfCiKBznP4PTbISKhmLRNwsX6VzbjuHwXPhZ63+2FlBXPtv pwbQ==
X-Received: by with SMTP id fp19mr50857317wjc.67.1437993642711; Mon, 27 Jul 2015 03:40:42 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Jul 2015 03:40:23 -0700 (PDT)
From: Romain Fliedel <romain.fliedel@gmail.com>
Date: Mon, 27 Jul 2015 12:40:23 +0200
Message-ID: <CAO5z66CK=B9pnRp4Hk4XDiuyqGXo-XGetn0FLzO9Au1rgu4cwA@mail.gmail.com>
To: acme@ietf.org
Content-Type: multipart/alternative; boundary=047d7bb03dce4361f5051bd8fc9e
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/ygrYurLoqQ-QrKxGRh8tRfdd5jc>
Subject: [Acme] Clarification about Identifier Validation Challenges
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 27 Jul 2015 10:40:46 -0000


I've been reading the spec, and I don't really understand why the reply to
validation challenges is not designed the same way as other api. If I
understand the spec correctly, instead of sending a JWS reply, the jws is
embedded in a json object containing 'type' and 'validation'.

For example the dvsni challenge response is :
  "type": "dvsni',
  "validation": {
    "header": { "alg": "HS256" },
    "payload": "qzu9...6bjn",
    "signature": "xxxxxxxxxxxxxxxxxx"

Why don't use a regular JWS as body for this challenge reply ?
In that case the reply would be:
    "signature": "xxxxxxxxxxxxxxxxxxx",
    "protected": "eyJub25jZ...In0",
    "header": {
        "alg": "RS256",
        "jwk": {
            "kty": "RSA",
            "n": "ox33_lEk....Eg9zM",
            "e": "AQAB"
    "payload": /* in cleartext for readability */ {
       "type": "dvsni",
       "token": "fgf...gfdg"

Also for the dns challenge I don't understand why there is
"clientPublicKey" attribute in the reply.
Still regarding dns challenge I am concerned about the length of the
"signature" generated when RS256 is used to sign the JWS object with a 4096
bits key. It will then exceed the maximum txt record length. maybe using a
hash of this signature would solve this ?