Re: [Trans] Certificate and Precertificate extensions ordering

Rob Stradling <rob.stradling@comodo.com> Thu, 11 September 2014 11:26 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BF01A0AEE for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 04:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 LMgh8ioAQO0F for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 04:26:41 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18F71A06FC for <trans@ietf.org>; Thu, 11 Sep 2014 04:26:40 -0700 (PDT)
Received: (qmail 30281 invoked by uid 1000); 11 Sep 2014 11:26:39 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 11 Sep 2014 12:26:39 +0100
Message-ID: <541186EE.2040203@comodo.com>
Date: Thu, 11 Sep 2014 12:26:38 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>, Eran Messeri <eranm@google.com>
References: <CA+i=0E5o_JEUquZpxhwiVKU3dvDTOHSf0fbeD7Nj7vrDwAkeSw@mail.gmail.com><CALzYgEcEpegaBt6-w+Y7Hs6EODdHUe=CFA6W=H8Afd9gxZjaSg@mail.gmail.com> <CABrd9STKow0=AJhxB7x1o-DJ3aTL0TkWbnZuGmvreEu3oTDeSw@mail.gmail.com>
In-Reply-To: <CABrd9STKow0=AJhxB7x1o-DJ3aTL0TkWbnZuGmvreEu3oTDeSw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1ZirPyId8fILclPkRwR4gpN1TOc
Cc: Erwann Abalea <eabalea@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Certificate and Precertificate extensions ordering
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 11:26:42 -0000

On 11/09/14 12:17, Ben Laurie wrote:
> On 11 September 2014 11:56, Eran Messeri <eranm@google.com> wrote:
>> The poison extension is removed from the Precertificate prior to the log
>> producing an SCT over it, so a client never has to know about it. What the
>> TLS client has to do is to remove the "embedded SCTs" extension  from the
>> certificate prior to validating the signature.
>
> This does imply that the remaining extensions have to be in the same
> order in both precert and cert, I think?

Yes.

I think this bit...
   "The Precertificate is constructed from the certificate to be issued
    by adding a special critical poison extension..."
...implies that the other extensions shouldn't be shuffled, but should 
we make it more explicit?

>> On Thu, Sep 11, 2014 at 11:40 AM, Erwann Abalea <eabalea@gmail.com> wrote:
>>>
>>> Bonjour,
>>>
>>> It seems there's no constraint on the order of extensions in the final
>>> certificate regarding to the Precert.
>>> Won't it be problematic if the browser wants to validate the SCT
>>> signatures by constructing the Precert from the final certificate? Where
>>> should a CA add the poisonous extension? And the future "redactedlabels"
>>> extension (it has no name)?
>>>
>>> --
>>> Erwann.
>>>
>>> _______________________________________________
>>> Trans mailing list
>>> Trans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trans
>>>
>>
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.