Subject: [Trans] Precertificate format

From: Ben Laurie <[email-masked]>
Date: Thu, 16 Oct 2014 15:09:13 +0000

We (the 6962-bis editors) would like to propose that we replace the
existing precertificate formats with a TBSCertificate wrapped in PKCS#7.
This lays to rest, we think, any possible confusion with X509v3 certs,
whilst allowing a simple mapping between the final cert and the pre-cert.

Obviously there are details to be nailed down, but before we do so, we'd
like to hear any discussion on the general idea.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Oct 2014 14:41:37 -0800

> like to hear any discussion on the general idea.

Please give this some attention - we've been trying to come to
agreement on precertificate format since the working group was
chartered, and it will be a glorious day indeed when we can close
the ticket.

Melinda

---

From: Stephen Davidson <[email-masked]>
Date: Mon, 20 Oct 2014 13:34:43 +0000

Hello:

What do you propose re the launch of CT in Chrome?  It would be preferable to 
have the actual CT implementation match the CT standard rather than for CAs to 
have to rejig the logging later.

Kind regards,

Stephen

From: Trans [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Thursday, October 16, 2014 12:07 PM
To: [email-masked]
Subject: [Trans] Precertificate format

We (the 6962-bis editors) would like to propose that we replace the existing 
precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to 
rest, we think, any possible confusion with X509v3 certs, whilst allowing a 
simple mapping between the final cert and the pre-cert.

Obviously there are details to be nailed down, but before we do so, we'd like 
to hear any discussion on the general idea.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Oct 2014 13:42:19 +0000

On Mon Oct 20 2014 at 2:37:43 PM Stephen Davidson <
[email-masked]> wrote:

> Hello:
>
>
>
> What do you propose re the launch of CT in Chrome?  It would be preferable
> to have the actual CT implementation match the CT standard rather than for
> CAs to have to rejig the logging later.
>
The CT launch in Chrome will implement RFC 6962.

>
>
> Kind regards,
>
> Stephen
>
>
>
>
>
>
>
>
>
> *From:* Trans [mailto:[email-masked]] *On Behalf Of *Ben Laurie
> *Sent:* Thursday, October 16, 2014 12:07 PM
> *To:* [email-masked]
> *Subject:* [Trans] Precertificate format
>
>
>

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 20 Oct 2014 15:42:34 +0200

Discussion around the format happened in mid/late september, the idea of a
CMS/PKCS#7 structure to hold the signature seems fine.
Additional questions come in: is the new format intended to *replace* or
*complement* the current one? If it's a replacement, what timeframe? CAs
are already doing software modifications and deployment, please be nice :)

The same question remains on the knowledge of the serial number before
generating the final certificate, with no objection so far, even with
arguments raised by Stephen Kent (valid ones, I used such HSMs in the past
for SET certs, the BBN SafeKeyper Signer).
It seems that no public CA concerned by CT is using such HSM, I guess they
all use a HSM for its key handling job and do certificate generation at a
software level.

-- 
Erwann.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 21 Oct 2014 13:51:18 +0000

> are already doing software modifications and deployment, please be nice :)

The proposal is to replace the current format.

In terms of timeframe, Google has not announced any plans to move to
6962-bis (and is not likely to before it becomes an RFC).

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2014 11:28:02 -0400

I think that's an excellent idea.

Steve

> existing precertificate formats with a TBSCertificate wrapped in 
> PKCS#7. This lays to rest, we think, any possible confusion with 
> X509v3 certs, whilst allowing a simple mapping between the final cert 
> and the pre-cert.
>
> Obviously there are details to be nailed down, but before we do so, 
> we'd like to hear any discussion on the general idea.
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Oct 2014 12:51:11 -0400

I think you are suggesting the format used in a .p7c file.  If I understand correctly, I fully support this idea.

Russ

> We (the 6962-bis editors) would like to propose that we replace the existing precertificate formats with a TBSCertificate wrapped in PKCS#7. This lays to rest, we think, any possible confusion with X509v3 certs, whilst allowing a simple mapping between the final cert and the pre-cert.
> 
> Obviously there are details to be nailed down, but before we do so, we'd like to hear any discussion on the general idea.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 28 Oct 2014 13:43:41 +0000

> I think you are suggesting the format used in a .p7c file.  If I understand correctly, I fully support this idea.

Hi Russ.  It's similar to .p7c in that it uses the SignedData structure.

 From RFC5652...
SignedData ::= SEQUENCE {
         version CMSVersion,
         digestAlgorithms DigestAlgorithmIdentifiers,
         encapContentInfo EncapsulatedContentInfo,
         certificates [0] IMPLICIT CertificateSet OPTIONAL,
         crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
         signerInfos SignerInfos }

A .p7c is a SignedData structure that contains one or more 
"certificates", but nothing useful in "encapContentInfo" or "signerInfos".

What we're proposing is a SignedData structure that contains zero or 
more "certificates" (CA certificates only), the TBSCertificate in 
"encapContentInfo" and a signature from the CA in "signerInfos".

We'll need to define a new ContentType OID that means "TBSCertificate".

-- 
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.