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
- [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Eran Messeri
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- Re: [Trans] Draft agenda Eran Messeri
- Re: [Trans] Draft agenda Daniel Kahn Gillmor
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- Re: [Trans] Draft agenda Melinda Shore
- Re: [Trans] Draft agenda Daniel Kahn Gillmor
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Phillip Hallam-Baker
- [Trans] CT for opportunistic STARTTLS in SMTP Paul Hoffman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Paul Hoffman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- [Trans] running code (was: Re: Draft agenda) Stephen Farrell
- Re: [Trans] Draft agenda Carl Wallace
- Re: [Trans] running code (was: Re: Draft agenda) Ben Laurie
- Re: [Trans] running code Stephen Farrell
- Re: [Trans] running code Ben Laurie
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] Draft agenda Carl Wallace
- Re: [Trans] Draft agenda Tomas Gustavsson
- Re: [Trans] running code Stephen Farrell
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] Draft agenda Rob Stradling
- Re: [Trans] running code (was: Re: Draft agenda) Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Ben Laurie
- Re: [Trans] running code Ben Laurie
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Phillip Hallam-Baker
- Re: [Trans] CT for opportunistic STARTTLS in SMTP Trevor Freeman