Subject: [Trans] draft-ietf-trans-rfc6962-bis

From: Russ Housley <[email-masked]>
Date: Mon, 26 Apr 2021 09:42:47 -0400

Hi.

A long time ago, I wrote an open source pyasn1 module for RFC 6962.  I just looked at the bis document to see what would need to change.  It turns out there there is a fair amount.

I was wondering if you would be willing to as an ASN.1 module as an appendix.  Right now, an implementer needs to do a fair amount of work to find all of the OID values and some of them do not have names.  For example:

     -  "eContentType" MUST be the OID 1.3.101.78.

By having an ASN.1 module, this OID will be easily recognized as a content type, and the syntax of the type:

   IMPORTS

  TBSCertificate
  FROM PKIX1Explicit-2009 -- RFC 5912
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkix1-explicit-02(51) }

   CONTENT-TYPE
   FROM CryptographicMessageSyntax-2010  -- RFC 6268
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

  ct-precertificateContent CONTENT-TYPE ::=
     { TYPE TBSCertificate IDENTIFIED BY
       id-ct-precertificateContent }

  id-ct-precertificateContent OBJECT IDENTIFIER ::= { 1 3 101 78 }

There are parallel benefits for the extension definitions.

I am willing to review the module and ensure that it compiles properly.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Apr 2021 13:59:53 +0000

>    I was wondering if you would be willing to as an ASN.1 module as an appendix.  Right now, an implementer needs to do a fair amount of work to find all of the OID values and some of them do not h…

That is a great idea.  If you are willing to do that, I am willing to make a PR to add it as an appendix (informative I assume?)

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Apr 2021 17:36:00 -0400

> On Apr 26, 2021, at 9:59 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

Informative seems fine to me.  The point is to help the implementer.

Below is the approach that I took for RFC 6962.  I had to make up names because there are no hints in the document in some cases.  Suggestions for the bis document are welcome.

Russ

= = = = = = = = 

RFC6963Module-2013
DEFINITIONS IMPLICIT TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS
  EXTENSION
  FROM PKIX-CommonTypes-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) }
 ;

SignedCertificateTimestampList ::= OCTET STRING

id-ce-embeddedSCT OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 2 4 2 }

id-ce-criticalPoison OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 2 4 3 }

id-kp-precertificateSigning OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 2 4 4 }

id-pkix-ocsp-SCT OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 11129 2 4 5 }

ext-embeddedSCT EXTENSION ::= { SYNTAX SignedCertificateTimestampList
   IDENTIFIED BY id-ce-embeddedSCT }

ext-criticalPoison EXTENSION ::= { SYNTAX NULL
   IDENTIFIED BY id-ce-criticalPoison }

ext-ocsp-SCT EXTENSION ::= { SYNTAX SignedCertificateTimestampList
   IDENTIFIED BY id-pkix-ocsp-SCT }
   
END

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Apr 2021 15:18:04 +0000

>   Below is the approach that I took for RFC 6962.  I had to make up names because there are no hints in the document in some cases.  Suggestions for the bis document are welcome.

https://github.com/google/certificate-transparency-rfcs/pull/330

Maybe change poison to include CT somewhere?  Since the other two extensions have SCT in them ...  not a big deal either way.

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 27 Apr 2021 11:57:59 -0400

On Tue, 27 Apr 2021 15:18:04 +0000
"Salz, Rich" <rsalz=[email-masked]> wrote:

> >   Below is the approach that I took for RFC 6962.  I had to make up
> > names because there are no hints in the document in some cases.
> > Suggestions for the bis document are welcome.
> 

Alas, this ASN.1 module is inapplicable to CTv2, as CTv2 uses all new
extensions and OIDs.

I believe the only two OIDs are:

1.3.101.75 - for the Transparency Information X.509v3 extension (Section 7.1)

1.3.101.78 - for the Precertificate CMS content type (Section 3.2)

Regards,
Andrew

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Apr 2021 12:20:20 -0400

I have made my first attempt at the ASN.1 module based on draft-ietf-trans-rfc6962-bis.  Please review.  Especially, are there any sections that use an ASN.1 structure that I missed?

Russ

= = = = = = = = 

CertificateTransparencyV2Module-2021
 -- { OID Needed, but no point in using a short one }
DEFINITIONS IMPLICIT TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS
  EXTENSION
  FROM PKIX-CommonTypes-2009 -- RFC 5912
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) }

  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010  -- RFC 6268
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  TBSCertificate

--
-- Section 3.2.  Precertificates
--

ct-tbsCertificate CONTENT-TYPE ::= {
  TYPE TBSCertificate
  IDENTIFIED BY id-ct-tbsCertificate }

id-ct-tbsCertificate OBJECT IDENTIFIER ::= { 1 3 101 78 }

--
-- Section 7.1.  Transparency Information X.509v3 Extension
--

ext-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-ce-transparencyInfo
   CRITICALITY { FALSE } }

id-ce-transparencyInfo OBJECT IDENTIFIER ::= { 1 3 101 75 }

TransparencyInformationSyntax ::= OCTET STRING

--
-- Section 7.1.1.  OCSP Response Extension
--

ext-ocsp-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-pkix-ocsp-transparencyInfo
   CRITICALITY { FALSE } }

id-pkix-ocsp-transparencyInfo OBJECT IDENTIFIER ::= id-ce-transparencyInfo

--
-- Section 8.1.2.  Reconstructing the TBSCertificate
--

ext-embeddedSCT EXTENSION ::= {
   SYNTAX SignedCertificateTimestampList
   IDENTIFIED BY id-ce-embeddedSCT
   CRITICALITY { FALSE } }

END

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Apr 2021 15:04:21 -0400

Should this part of the document also talk about validating CT v1 OCSP extensions?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 27 Apr 2021 15:59:23 -0400

> Should this part of the document also talk about validating CT v1 OCSP

No.

This document only talks about v2, because v1 and v2 may coexist, but
they're not interchangable with respect to policy. 8.1.1 already discusses
the obtaining of SCTs from OCSP by way of reference to Section 6 (and 6.5)

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Apr 2021 12:32:15 -0400

Indeed.  Rich was quick on the trigger.  I shared the module that I had developed for RFC 6962, and then a day later I proposed one for this Internet-Draft.

Russ

> On Apr 27, 2021, at 11:57 AM, Andrew Ayer <[email-masked]> wrote:
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Apr 2021 16:59:31 +0000

>   Indeed.  Rich was quick on the trigger

Yes, I figure once I make a PR the community will fix it :)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Apr 2021 19:32:19 +0000

>   I have made my first attempt at the ASN.1 module based on draft-ietf-trans-rfc6962-bis.  Please review.  Especially, are there any sections that use an ASN.1 structure that I missed?

Looks okay to me.  You have authority for some OID arc, right?  Just pick one :)

In order to encourage comments, I have updated the PR at https://github.com/google/certificate-transparency-rfcs/pull/330

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Apr 2021 15:35:16 -0400

I am the IANA expert for that registry, but it will not be assigned until after IETF Last Call.

Russ

> On Apr 30, 2021, at 3:32 PM, Salz, Rich <[email-masked]> wrote:
>