Subject: [lamps] Changes to pre-registered OIDs

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 9 Nov 2021 17:06:08 +0000

Russ

In my talk yesterday I asked, if it is possible to perform some changes to the pre-registered OIDs in CMP Updates.
I understood that this is not supported. To more clearly understand the restrictions, I provide some examples.

Example 1, changing the OID decimal value.
20       id-it-rootCaCert --> 18       id-it-rootCaCert   (and moving id-it-rootCaKeyUpdate and id-it-certReqTemplate one position behind)
This is to rearrange the OID addressing the change from providing the root ca cert in the genm body instead of the generalInfo header field. (CMP Updates, Section 2.14)
I understood changing the OID decimal value is not possible, right?

Example 2, changing the OID Description.
20       id-it-rootCaCert --> 20       id-it-oldTrustAnchor
This is to rename the root ca cert in alignment with its extended scope also allowing a publicKey only as trust anchor instead of a certificate. (CMP Updates Section 2.14)
Is this possible?

Example 3, changing the OIDs ASN.1 syntax.
      GenRep:    {id-it 17}, SEQUENCE SIZE (1..MAX) OF
                             CMPCertificate | < absent >
-->
      GenRep:    {id-it 17}, SEQUENCE SIZE (1..MAX) OF
                             CaCertsContent | < absent >
      CaCertsContent ::= SEQUENCE {
        intermediateCaCerts          [0] CMPCertificate,
        trustAnchors              [1]  CMPCertificate }
This should make it possible to differentiate between trust anchors like root ca certificates and intermediate ca certificates. (not reflected in CMP Updates now, but discussed internally)
Is this possible?

We can definitely live without all these changes. It would finally make the final draft a little more perfect.  :-)
But my main goal remains to finalize the document now.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Tue, 9 Nov 2021 12:24:49 -0500

Hendrik:

RE: Example 1 and Example 3:

Once the assignment is made in the IANA registry, I am strongly opposed to assigning a different ASN.1 type with that OID.  Doing so would lead to interoperability issues.  If a different type is needed, then a new OID should be assigned.

RE: Example 2:

Changing (or adding) a description has been done.  This is a NOTE that gets added to the IANA registry.  For example:

   Note: id-alg-dhPop-sha1 is also known as id-alg-dh-pop.

In this case, the one used in the newest RFC appears in the IANA table, and the older one is explained in the note.  Also, the ASN.1 module defines both:

   id-it-oldTrustAnchor OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 7 4 20 }

   id-it-rootCaCert OBJECT IDENTIFIER ::= id-it-oldTrustAnchor 

Russ

> On Nov 9, 2021, at 12:06 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 9 Nov 2021 17:29:11 +0000

Russ

Thanks a lot for this clarification.

Hendrik

> Von: Russ Housley <[email-masked]>
> Gesendet: Dienstag, 9. November 2021 18:25
> 
> Hendrik:
> 
> Once the assignment is made in the IANA registry, I am strongly opposed to
> assigning a different ASN.1 type with that OID.  Doing so would lead to
> interoperability issues.  If a different type is needed, then a new OID should be
> assigned.
> 
> RE: Example 2:
> 
> In this case, the one used in the newest RFC appears in the IANA table, and the
> older one is explained in the note.  Also, the ASN.1 module defines both:
> 
> > 20       id-it-rootCaCert --> 18       id-it-rootCaCert   (and moving id-it-
> rootCaKeyUpdate and id-it-certReqTemplate one position behind)
> > This is to rearrange the OID addressing the change from providing the
> > root ca cert in the genm body instead of the generalInfo header field. (CMP
> Updates, Section 2.14) I understood changing the OID decimal value is not
> possible, right?
> >
> > This is to rename the root ca cert in alignment with its extended
> > scope also allowing a publicKey only as trust anchor instead of a certificate.
> (CMP Updates Section 2.14) Is this possible?
> >
> > This should make it possible to differentiate between trust anchors
> > like root ca certificates and intermediate ca certificates. (not reflected in CMP
> Updates now, but discussed internally) Is this possible?
> >
> > We can definitely live without all these changes. It would finally
> > make the final draft a little more perfect.  :-) But my main goal remains to
> finalize the document now.
> >
> > Hendrik

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Nov 2021 16:25:46 -0500

Roman:

As discussed on Monday, the LAMPS WG would like to get early (permanent) allocation of two OIDs from IANA.

The relevant part of draft-ietf-lamps-cmp-updates-13 is quoted below.

The OID need to be allocated in SMI Security for PKIX CMP Information Types (1.3.6.1.5.5.7.4).
(https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.4)

Thanks,
  Russ

= = = = = = = = =
2.16.  New Section 5.3.19.17 - CRL update retrieval

   The following subsection introduces the PKI general message using id-
   it-crlStatusList and id-it-crls.  Details are specified in the
   Lightweight CMP Profile Section 4.3
   [I-D.ietf-lamps-lightweight-cmp-profile].  Insert this section after
   new Section 5.3.19.16:

   5.3.19.17.  CRL update retrieval

   This MAY be used by the client to get new CRLs, specifying the source
   of the CRLs and the thisUpdate value of the latest CRL it already
   has, if available.  A CRL source is given either by a
   DistributionPointName or the GeneralNames of the issuing CA.  The
   server shall provide only those CRLs that are more recent than the
   ones indicated by the client.

      GenMsg:    {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus
      GenRep:    {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF
                               CertificateList  |  < absent >

      CRLSource ::= CHOICE {
         dpn          [0] DistributionPointName,
         issuer       [1] GeneralNames }

      CRLStatus ::= SEQUENCE {
         source       CRLSource,
         thisUpdate   Time OPTIONAL }

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 15 Nov 2021 15:32:05 +0000

Russ

Thank you for starting the registration.
As soon as the OIDs are assigned, I will add them to the document.

Hendrik

> Gesendet: Mittwoch, 10. November 2021 22:26
> 
> Roman:
> 
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> iana.org%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xml%23smi-
> numbers-
> 1.3.6.1.5.5.7.4&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%
> 7Ce429a066d36b4f2cf3da08d9a490ab14%7C38ae3bcd95794fd4addab42e149
> 5d55a%7C1%7C0%7C637721763514579270%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C1000&amp;sdata=9g3dUqOyT2qDNXWCBgw%2B7szmus2EI4jLWp0HTGC0
> zIM%3D&amp;reserved=0)
> 
> Thanks,
>   Russ
> 
> = = = = = = = = =