Subject: [Trans] Walking through the issue tracker: Ticket #4

From: Melinda Shore <[email-masked]>
Date: Thu, 03 Jul 2014 11:47:50 -0800

Hey, all:

We have 10 open issues in the trans issue tracker
(http://trac.tools.ietf.org/wg/trans/trac/report/1)
and I'd like to walk through them and see where things
stand, what can be closed, etc.  I'm going to take the
liberty of assuming that the list is not comprehensive, as
nothing's been added in the last two months and nothing
from Steve's recent comments have been added.  And that's
okay - if the issue tracker isn't useful we don't need to
use it.

So, on to actual content: Ticket #4 asks whether signatures
should be treated consistently across certificates and
precertificates - i.e. should the TBS be signed in both
cases, rather than the entire certificate as is currently
specified for certificates.

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Jul 2014 13:13:17 +0100

> specified for certificates.

Given that there's a certain amount of angst about precertificates and
PKI rules, it could be that we really want to sign some other
structure altogether, at least for precertificates.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 08 Jul 2014 18:16:26 -0800

> structure altogether, at least for precertificates.

Is there a proposal for that that's ready for discussion?

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Jul 2014 17:49:49 +0100

> Is there a proposal for that that's ready for discussion?

Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate
(or at least, all the data that is in it). What we might want to do,
at least for Precertificates, is to sign it in a way that is not
X.509v3, to completely remove all question that it could be used as an
X.509v3 certificate, or be subject to their validation rules.

As for exactly how it is signed, I don't have strong feelings about
that. Is there some appropriate RFC that specifies how to sign some
arbitrary binary blob using RSA or EC keys?

In any case, I am conflating two issues. Trac issue 4 is about what
the _log_ signs. Just signing the TBSCertificate certainly makes some
kind of sense, from a consistency POV. Sorry for the confusion.

---

From: Matt Palmer <[email-masked]>
Date: Tue, 15 Jul 2014 15:15:44 +1000

> arbitrary binary blob using RSA or EC keys?

struct {
    digitally-signed TBSCertificate;
    opaque TBSCertificate<1..2^24-1>;
} Precertificate;

?

- Matt

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Jul 2014 11:21:50 +0100

>     opaque TBSCertificate<1..2^24-1>;

Hmm. That's a tempting thought!

---

From: Rob Stradling <[email-masked]>
Date: Tue, 15 Jul 2014 12:09:33 +0100

> On 15 July 2014 06:15, Matt Palmer <[email-masked]> wrote:
<snip>
> Hmm. That's a tempting thought!

"SIGNED", defined by X.509, is one of the ASN.1 ways to sign arbitrary 
blobs.  It's used for signing certificates, CRLs, CSRs, OCSP responses, etc.

RFC2459 expressed it as...
   "SIGNED { ToBeSigned } ::= SEQUENCE {
       toBeSigned  ToBeSigned,
       algorithm   AlgorithmIdentifier,
       signature   BIT STRING
    }

    Certificate            ::=   SIGNED { SEQUENCE {
       version                 [0]   Version DEFAULT v1,
       serialNumber                  CertificateSerialNumber,
       ..."

(However, for some reason RFC3280/5280 dropped "SIGNED" and changed the 
certificate definition to...
   "Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signature            BIT STRING  }")

We could define TBSPrecertificate as an ASN.1 structure that is very 
similar to, but incompatible with, TBSCertificate.  And then we could 
define...
    Precertificate   ::=   SIGNED { TBSPrecertificate }

An alternative ASN.1 way to sign arbitrary binary blobs is CMS 
(originally called PKCS#7).  See RFC5652.
A Precertificate could be a CMS object that uses the Signed-data content 
type to carry a TBSCertificate.

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

---

From: Kyle Hamilton <[email-masked]>
Date: Tue, 15 Jul 2014 12:37:02 -0700

> Hmm. That's a tempting thought!

Why not use a modified Certificate structure with a non-optional,
explictly-tagged (tag 1 or something) datum in the place of the Version
field?  Especially if it wasn't an INTEGER, it would cause any
conformant Certificate parser to reject it.  (Anything that checks to
see that the first item either isn't tagged or has tag 0 will refuse to
parse it.)

-Kyle H