Re: [TLS] Proposed Change to Certificate message (#654)

Brian Smith <> Fri, 23 September 2016 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B1BA12BA72 for <>; Thu, 22 Sep 2016 19:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5B5YRfso_Ua for <>; Thu, 22 Sep 2016 19:17:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8D3C12BA47 for <>; Thu, 22 Sep 2016 19:17:03 -0700 (PDT)
Received: by with SMTP id r192so2879050ita.0 for <>; Thu, 22 Sep 2016 19:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mwCofgttRXCUlY0DZo6hq68jh2xmR2FrKf5x2GTy2po=; b=F32YHM8+ICgnmUsveVo4pcdVryKdEfA2h0amIUq/2amdLXie1pu1fFUlU6ybafpr0G wgr+SZOnptHe87DgmLht52zFF2sjOnmpSutPYH/aZm8/RWcxggjrFAswLjrXpFNL/3vO abXXyqqnwQBsp6yq1762W1iwCoyL3l6s8QN0c2jUR7uO0lkmSMmcIqZC1DQ4/aasTppM MhNv+3dTrn0WJdqvsRqSe8522G4mZg5lxlSOyUYaUfaeC71UtdDt1jFpaRLntqnM5Bou qrl3nb4/d3wCbFihsxUOPJchnXx86hFgrBIFBavG4Eepz7AlGUgQgLC2MkVPsx4aSGrV ThEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mwCofgttRXCUlY0DZo6hq68jh2xmR2FrKf5x2GTy2po=; b=FFW7z2x6/HBCWG03m6DPitfBqktNdeGMSCIJ3oupP95WSEa2GbCcAhuf9PNk23WHYd hA5hWIiw8MK8/XLKCI0YBq1FFKjPuzFxaFMut1takJwb24UQ0tERolgkQWrtYrs7j4ow 9LMab1d0F9XSOLyb326rwM+0qpruZabUZPZgzHT4lhnT7PvRcu/Zm7GUNvLIvi2I/uFJ WICwLbrjb6qxRmGGtwaLARhV+DtoV7vu+kZcH4mwcor9LeTHj9CdEK3/MPKYj4vlG/iw 4hiWZkLnvE2vcwBqwp/jnwBzxV0VxsBHyksWlv3DbCjsvE6KddA+jBf9VIKjm1sR7ta7 EkXQ==
X-Gm-Message-State: AA6/9RlXEUdmiRxnDa80iEQaYpGRgNEr4gC1Z8OYmJd4yzBV53JDrn1hVyBMEU/cxIsLW4aWRp6EclJId6/P1Q==
X-Received: by with SMTP id x65mr584728itf.54.1474597023269; Thu, 22 Sep 2016 19:17:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Sep 2016 19:17:02 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Brian Smith <>
Date: Thu, 22 Sep 2016 16:17:02 -1000
Message-ID: <>
To: Nick Sullivan <>
Content-Type: multipart/alternative; boundary="94eb2c05bce8c25af0053d235f8c"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Proposed Change to Certificate message (#654)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Sep 2016 02:17:06 -0000

Nick Sullivan <> wrote:

> PR:
> This change adds a set of extensions to the Certificate message. With this
> change, the Certificate message can now hold all extension messages that
> are certificate-specific (rather than connection-specific). This change
> also resolves the anomaly of OCSP messages appearing before certificates in
> the handshake.

There are two ways that such a thing could be done. How your proposal

    opaque ASN1Cert<1..2^24-1>;
    struct {
        opaque certificate_request_context<0..2^8-1>;
        ASN1Cert certificate_list<0..2^24-1>;
        Extension extensions<0..2^16-1>;
    } Certificate;


    opaque ASN1CertData<1..2^24-1>;
    struct {
        ASN1CertData cert_data;
        Extension extensions<0..2^16-1>;

    struct {
        opaque certificate_request_context<0..2^8-1>;
        ASN1Cert certificate_list<0..2^24-1>;
    } Certificate;

I think you are right that the SCT and the OCSP response are
per-certificate. In particular, they are not per-certificate-chain, so to
me the latter form, where each certificate in the chain gets its own
extension list, makes more sense to me. Would you consider changing the
proposal to the second form?