Subject: [Trans] Where do things stand with the precertificate format discussion?

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Sep 2014 13:45:50 -0800

It looks like we've got two closely-related discussions:

1) precertificate format (representation), and
2) precertificate contents

There've been a couple of proposals for alternative representation,
including TBS (alternatively, the CertTemplate format from 4211) and
CRMF, and there seems to be some agreement congealing around Erwann's
summary:

>IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a
>signedData content-type, for which the data is the TBSCertificate
>(name-redacted or not, no necessary poison extension). The SignerInfo
>refers to the PreCert issuer (CA or dedicated issuer, same as now).

>It can only work if the log signs the content (=TBSCertificate) and not
>the whole CMS, thus ignoring the PreCert issuer signature. Leaving that
>signature aside isn't more risky than it is now because it's already
> the case (the log removes the poison extension before signing the
> resulting certificate, right?).

with an open question around serial numbers.

Related, there's a proposal on the table to walk through cert data and
justify SCT contents.

Does this sound about right?

Melinda

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 Sep 2014 15:35:07 -0700

>>refers to the PreCert issuer (CA or dedicated issuer, same as now).

CMS is not a good format for the PreCert, because CMS is highly
complicated and unnecessarily complex for this purpose. And, in
particular, CMS is specified as a BER-encoded format, not a
DER-encoded format, and it isn't reasonable to require implementations
to support a BER-encoded format for CT when all other things they
process are DER-encoded. In particular, some implementations may have
specialized DER decoders that cannot be practically adapted to deal
with BER.

I previously suggested an alternative syntax that would be much easier
to implement:
http://www.ietf.org/mail-archive/web/trans/current/msg00500.html

> Related, there's a proposal on the table to walk through cert data and

There is a proposal for that, but I don't think it has much support. I
myself do not think that would be a useful thing to do.

Cheers,
Brian

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Sep 2014 22:02:58 -0800

> http://www.ietf.org/mail-archive/web/trans/current/msg00500.html

Right, thanks.  My real question is whether or not we've got
something on which there's sufficient agreement to move forward.

Melinda

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 18 Sep 2014 23:18:23 +0200

Bonjour,

2014-09-18 0:35 GMT+02:00 Brian Smith <[email-masked]>:

> DER-encoded format,

BER/DER doesn't concern the payload of the CMS (here, the TBSCertificate,
which will be DER encoded anyway).
CMS is complex and flexible, but this complexity is already known, and it
will be handled by logs+monitors+auditors only.
More important, CMS is already present in the bestiary of objects that
anyone involved in PKI knows.

and it isn't reasonable to require implementations
> specialized DER decoders that cannot be practically adapted to deal

Fine. Let's say that for the purpose of CT, the CMS SHOULD be DER encoded.
Those CMS objects will still be RFC5652 compliant (DER is a subset of BER).

> http://www.ietf.org/mail-archive/web/trans/current/msg00500.html

That's another solution, but it will force everyone to add this specific
object to their libraries. It will require more efforts.

-- 
Erwann.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Sep 2014 13:18:41 -0400

Melinda,

> justify SCT contents. Does this sound about right?

Based on Ben's response to my attack analysis, in which indicated that 
he had a much
broader definition for mis-issuance, I plan to find the relevant CABF 
docs, and generate
the appendices that I think are needed to define the term accurately. 
I'll revise my
attack analysis text, including the definition of mis-issuance. Once 
that is done,
I'll generate the mapping between cert content and requirements for SCT 
inclusion.

I hope to provide some new text next week.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Fri, 19 Sep 2014 14:35:38 -0800

> I hope to provide some new text next week.

Excellent, thank you.

Melinda