Re: [Trans] Draft agenda

Rob Stradling <rob.stradling@comodo.com> Wed, 26 February 2014 11:57 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 C18D91A02B4 for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 03:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, 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 Wseb4I4zI6yH for <trans@ietfa.amsl.com>; Wed, 26 Feb 2014 03:57:52 -0800 (PST)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09C1A02AC for <trans@ietf.org>; Wed, 26 Feb 2014 03:57:51 -0800 (PST)
Received: (qmail 31392 invoked by uid 1000); 26 Feb 2014 11:57:48 -0000
Received: from nigel.brad.office.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; Wed, 26 Feb 2014 11:57:48 +0000
Message-ID: <530DD6BC.8080207@comodo.com>
Date: Wed, 26 Feb 2014 11:57:48 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>, Phillip Hallam-Baker <hallam@gmail.com>
References: <53063600.4020102@gmail.com> <CALzYgEe0XrQdKDZN3_dwFLnM87+TXyYRMzj4ZGe5xKi-T_5V+g@mail.gmail.com> <530B86F6.5040201@gmail.com> <CABrd9SSpyw4nJ9t7X0WDeN+1MnhD+__-QXLOQXYs=h2JCUrwDg@mail.gmail.com> <CAMm+Lwj4XniVS_n+M3TmT_LM+P6H6HGgcnhMezUjnupKXzwwdg@mail.gmail.com> <CABrd9STabJA4Fp75HfC7ORR1LQZT+q0DDuB61O0JGBOt31cpmQ@mail.gmail.com> <CAMm+LwgT8MEG+Svr3zmMYYPrQNEXwtNPL0m7CjYFHKUAKKbfFQ@mail.gmail.com> <CABrd9STQQ69cPo3F5c22__aGbPAKV3AXnTFB47yd3s7+SQOpww@mail.gmail.com>
In-Reply-To: <CABrd9STQQ69cPo3F5c22__aGbPAKV3AXnTFB47yd3s7+SQOpww@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rrGTrB0khyfOqTQPibphiB9xbas
Cc: Melinda Shore <melinda.shore@gmail.com>, "trans@ietf.org" <trans@ietf.org>, Eran Messeri <eranm@google.com>
Subject: Re: [Trans] Draft agenda
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: Wed, 26 Feb 2014 11:57:55 -0000

On 26/02/14 11:28, Ben Laurie wrote:
> On 25 February 2014 12:36, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie <benl@google.com> wrote:
>>> On 24 February 2014 19:17, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>>> What exactly is a 'precertificate'. Either something is a cert or it is
>>>> not.
>>>>
>>>> If it parses as an X.509v3 certificate then it is an X.509v3 certificate
>>>> and thats an end to it.
>>>
>>> Indeed, and a precertificate is a certificate. RFC 6962 defines what
>>> exactly it is.
>>>
>>> Not sure where you're going with this.
>>
>> Ritual compliance with the existing PKIX spec.
>>
>> Having two end entity certs with the same serial number is going to be a
>> problem.
>
> Not for ritual compliance. Same serial number _and issuer_ is a
> problem. CT does not require this.

That's true, but CT does _permit_ same serial number and issuer.

I think Phill is saying that he wants ritual compliance to be the only 
option available.

>>>> If it is not then it is probably a CSR which would seem to be the
>>>> existing PKIX structure that fits its purpose.

Actually, I disagree with that.  A Precertificate is not a certificate 
signing _request_.  It's a certificate signing _promise_.

>>> Not really - a precertificate needs to be signed.
>>
>> CSRs are signed.
>
> But not by the right key - i.e. a change of spec would be required. I
> think you might be able to cram the missing fields into attributes in
> PKCS#10, though (which would also require additional spec).

That would involve reinventing several wheels and making the whole thing 
far more complicated.  All just to achieve ritual compliance.

But if we must have ritual compliance with 5280, then my preferred 
solution is to "poison" the Issuer Name in the Precertificate.

For example...
Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA
Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA

Sign both the Precertificate and the Certificate with the same CA 
private key.  Use the same serial number for both.

It wouldn't matter whether or not there exists a CA Certificate with the 
Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA".

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online