Subject: [Trans] Alternate formats for Precertificates

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 15:30:05 +0000

On 26 February 2014 14:13, Tomas Gustavsson <[email-masked]> wrote:
>
> Did anyone consider using RFC4211 CRMF requests as "pre-certificates"?
> CRMF has both issuer and serialNumber, as well as extensions. The
> CertTemplate of RFC4211 is basically a TBSCertificate.

Hmm. So it is. I had not come across this RFC before.

Does anything implement it?

>
> Cheers,
> Tomas
>
> PS: time to change subject of the thread?
>
>
> On 02/26/2014 05:46 AM, Rob Stradling wrote:
>> On 26/02/14 13:33, Carl Wallace wrote:
>>>>>
>>>>> While I agree that lack of a CA certificate with the matching naming
>>>>> really doesn¹t matter, breaking name chaining seems like an odd way to
>>>>> maintain ³ritual compliance".  Why not bump the version number instead?
>>>>> v4 could be defined as a pre-certificate containing a poison extension
>>>>> and
>>>>> a serial number that matches its v3 counterpart.
>>>>
>>>> Hi Carl.  I briefly discussed the idea of changing the version number
>>>> with Ben a few months ago...
>>>
>>> Sorry for the rehash.  There are occasions where I miss an email in this
>>> list:-)
>>
>> No need to apologize.  It was an off-list discussion.  :-)
>>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Feb 2014 10:39:30 -0500

We can easily knock up some ASN.1

The only criteria is that it isn't mistaken for an X.509v3 cert. We can
wrap TBSCertificate any which way, just put the signature ahead of the cert
and the job is done.

But as an aside, isn't it rather a bug in the ASN.1 encoding that two such
structures could be confused? I think that is something we might want to
consider in the JSON world. I always put a unique format specifier in a
signed object to prevent substitution attacks. One of my dislikes of XML
Signature is it is difficult to see this is done right.

-- 
Website: http://hallambaker.com/

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 26 Feb 2014 08:02:18 -0800

> Does anything implement it?

Absolutely. It is used in CMP (RFC4210). EJBCA has had support for it as 
a request format for years, so we have code for both producing and 
parsing of course.

BouncyCastle has Java APIs for CMP/CRMF.
http://www.bouncycastle.org/

cmpforopenssl supports it I believe, C API and command line.
http://sourceforge.net/apps/mediawiki/cmpforopenssl/index.php?title=Main_Page

I don't know why I did not think of this earlier, since I use it all the 
time. CMP with CRMF is used in many systems in production. Card 
management, LTE base stations (3GPP standardization), some routers etc.

Re-using existing RFC always feels good :-)

Cheers,
Tomas

---

From: "Goulet, Walter" <[email-masked]>
Date: Wed, 26 Feb 2014 16:07:29 +0000

Another +1 for RFC4211/4210; my company's certificate issuance platform has supported CMP/CMRF for many years and we have several large customers using it for LTE applications as Tomas described below.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Tomas Gustavsson
Sent: Wednesday, February 26, 2014 10:02 AM
To: [email-masked]
Subject: Re: [Trans] Alternate formats for Precertificates

> Does anything implement it?

Absolutely. It is used in CMP (RFC4210). EJBCA has had support for it as a request format for years, so we have code for both producing and parsing of course.

I don't know why I did not think of this earlier, since I use it all the time. CMP with CRMF is used in many systems in production. Card management, LTE base stations (3GPP standardization), some routers etc.

Cheers,
Tomas

>>>>>> While I agree that lack of a CA certificate with the matching 
>>>>>> naming really doesn¹t matter, breaking name chaining seems like 
>>>>>> an odd way to maintain ³ritual compliance".  Why not bump the version number instead?
>>>>>> v4 could be defined as a pre-certificate containing a poison 
>>>>>> extension and a serial number that matches its v3 counterpart.
>>>>>
>>>>> Hi Carl.  I briefly discussed the idea of changing the version 
>>>>> number with Ben a few months ago...
>>>>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 26 Feb 2014 16:19:54 +0000

> Re-using existing RFC always feels good :-)

RFC4211 says:
   "The fields of CertRequest have the following meaning:
       ...
       serialNumber MUST be omitted.  This field is assigned by the CA
       during certificate creation.

       signingAlg MUST be omitted.  This field is assigned by the CA
       during certificate creation."

So that's two ways we would need to violate RFC4211 in order to use its 
CertTemplate format for Precertificates.

In contrast, allowing a Precertificate/Certificate pair to use the same 
serial number only violates RFC5280 in one way.  (Oh, and to me, reusing 
the TBSCertificate format feels good too! ;-) )

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

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 26 Feb 2014 08:31:09 -0800

> CertTemplate format for Precertificates.

Seems like very minor violations to me. In addition using CRMF would 
remove the need for the poison certificate extension. CRMF also gives 
more flexibility as you (RFC 6962 that is) can choose which fields to 
include and/or exclude, potentially answering to questions like privacy 
issues and such.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Feb 2014 16:45:04 +0000

On 26 February 2014 16:31, Tomas Gustavsson <[email-masked]> wrote:
> Seems like very minor violations to me. In addition using CRMF would remove
> the need for the poison certificate extension. CRMF also gives more
> flexibility as you (RFC 6962 that is) can choose which fields to include
> and/or exclude, potentially answering to questions like privacy issues and
> such.

We're only discussing alternatives to avoid breaking ritual compliance
with the RFC, so selecting another one we have to violate hardly seems
like forward motion.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 26 Feb 2014 08:48:16 -0800

<snip>

> with the RFC, so selecting another one we have to violate hardly seems

Just bringing some more alternatives to the table.
I'm sure modifying RFC4211 is easier than modifying RFC5280 ;-)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Feb 2014 08:58:13 -0800

RFC 4211 is also somewhat ambiguous. It says:

   CertTemplate ::= SEQUENCE {
      version      [0] Version               OPTIONAL,
      serialNumber [1] INTEGER               OPTIONAL,
      signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
      issuer       [3] Name                  OPTIONAL,
      validity     [4] OptionalValidity      OPTIONAL,
      subject      [5] Name                  OPTIONAL,
      publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
      issuerUID    [7] UniqueIdentifier      OPTIONAL,
      subjectUID   [8] UniqueIdentifier      OPTIONAL,
      extensions   [9] Extensions            OPTIONAL }

And:

If it "MUST be omitted", it is not optional. So, a document updating RFC 4211 to fix this error, at least for the limited use of CT, seems fine.

--Paul Hoffman

---

From: Carl Wallace <[email-masked]>
Date: Wed, 26 Feb 2014 12:05:42 -0500

On 2/26/14, 11:58 AM, "Paul Hoffman" <[email-masked]> wrote:

>If it "MUST be omitted", it is not optional. So, a document updating RFC
>4211 to fix this error, at least for the limited use of CT, seems fine.

If this is all that is sought, why not just use TBSCertificate as Rob
suggested and be done?  How would that run afoul of ritual compliance?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Feb 2014 09:12:06 -0800

> suggested and be done?  How would that run afoul of ritual compliance?

Because I couldn't figure out what he meant, and he followed by a smilely so I figured it wasn't serious.

When you say "just use a TBSCertificate", you mean that CT use that instead of a certificate structure, yes?

--Paul Hoffman

---

From: Carl Wallace <[email-masked]>
Date: Wed, 26 Feb 2014 12:13:55 -0500

>instead of a certificate structure, yes?

Yes.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Feb 2014 08:29:55 -0900

>>> Seems like very minor violations to me. In addition using CRMF would
remove
> I'm sure modifying RFC4211 is easier than modifying RFC5280 ;-)

(Apologies for the crispy formatting, I'm typing on a phone).  Anyway, that
would be essentially correct - there are issues around thongs like deployed
base, and how much would or could break as a result.  These are the sorts
of questions for which "ritual compliance" is unhelpful language.

---

From: "Robin Alden" <[email-masked]>
Date: Wed, 26 Feb 2014 18:39:33 -0000

> From: Carl Wallace
> Sent: 26 February 2014 17:14
> 
> > Paul Hoffman said..
> >

But I think CT wants the pre-certificate signed by a key which it can
verify that the CA controls, and a signed TBSCertificate is a
Certificate.

Regards
Robin Alden
Comodo

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Feb 2014 15:46:53 +0000

<snip>
> Because I couldn't figure out what he meant, and he followed by a smilely so I figured it wasn't serious.

Paul, sorry for being unclear.

I was simply trying to point out that reusing a structure from RFC4210 
and reusing a structure from RFC5280 are both equivalent in terms of 
structure reuse and feel-good factor.

(Tomas seemed to be implying that RFC4210 scored higher on these metrics).

---

From: Rob Stradling <[email-masked]>
Date: Thu, 27 Feb 2014 16:00:28 +0000

> If it "MUST be omitted", it is not optional. So, a document updating RFC 4211 to fix this error, at least for the limited use of CT, seems fine.

Can a CA private key sign a CertTemplate structure?
Or rather, could RFC5280-compliant software verify a CA-signed 
CertTemplate if the corresponding CA certificate has the keyCertSign Key 
Usage bit set but _not_ the digitalSignature bit set?
I don't think it could.

So, I think we'd have to update RFC5280 - relaxing some of the Key Usage 
rules - in order to permit the RFC4211 CertTemplate structure to be used 
for Precertificates.

And if we're going to update RFC5280, surely the simplest update would 
be to permit an RFC6962-compliant Precertificate/Certificate pair to 
share the same serial number?

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 27 Feb 2014 09:23:17 -0800

> (Tomas seemed to be implying that RFC4210 scored higher on these metrics).

Since there is some unease on the mailing list regarding duplication of 
issuer/serialNumber pairs, I was merely pointing out that there is an 
alternative that does not affects the CT RFC in any structural way. 
Simply using another, already existing ASN.1 structure.

I have no problem living with the present use of TBSCertificates if 
everyone agrees. I'm not much of a fan of wacky ideas however, when 
there are standard based alternatives.

Cheers,
Tomas