Subject: [lamps] CMP Updates ASN.1

From: Russ Housley <[email-masked]>
Date: Thu, 22 Jul 2021 13:48:23 -0400

Right now, the CMP Update document is importing Attribute from RFC 5652.  It could also import Attribute from RFC 5280.  The two have the same syntax, but I believe that the use of Attribute is about naming attributes for the subject name in the certificate.  In the pyasn1-modules open source routines, the two kings of attributes are not mixed.  This means that at ASN.1 decode time, when an OID is encountered, only one of the lists will be searched to determine the associated type to proceed with the decode.  If no match is found, that open type is not decoded, and the application needs to handle that part of the message.  I do not know if other libraries have this issue or not.

My suggestion is that Attribute be imported from RFC5280 so that the proper list will be searched.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Jul 2021 15:21:04 -0400

I'm digging into this a bit deeper, and I see that CMS attributes are being used.  The localKeyId defined in PKCS#9 is being used as a CMS attribute.

Russ

> On Jul 22, 2021, at 1:48 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Jul 2021 17:40:01 -0400

I was just looking at RFC 4210, and the body of the document talks about this:

   id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
   AltCertTemplate ::= AttributeTypeAndValue

This control does not appear in the ASN,1 module, even though RFC 4210 is the source of this definition.

Should we add it now, in the same part of the module where other new controls are defined?

Russ

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 22 Jul 2021 21:41:33 +0000

IMHO, yes. 

Regards,
Uri

> On Jul 22, 2021, at 17:40, Russ Housley <[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 23 Jul 2021 06:57:50 +0000

Russ

Thank you for looking into this.

You are right, id-regCtrl-altCertTemplate is not defined in the ASN.1 module in RFC 4210. RFC 4210 mentions id-regCtrl-altCertTemplate only in Appendix C.
IANA refers to RFC 4212 as source for id-regCtrl-altCertTemplate, but RFC 4212 does not have an ASN.1 module.

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> Gesendet: Donnerstag, 22. Juli 2021 23:40
> An: LAMPS WG <[email-masked]>
> Betreff: Re: [lamps] CMP Updates ASN.1
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.brockha
> us%40siemens.com%7C43dc81094b824e429b7308d94d594ec5%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C637625868246127176%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000&amp;sdata=qbuL50LvcYf%2F1gTkq6QPEMR4i54kNto
> NxCdqFfZD%2BtM%3D&amp;reserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 23 Jul 2021 07:00:30 +0000

Russ

Yes, I make use of localKeyId in EnvelopedData.
What is your recommendation, should I leave it as is, or change the import of Attribute to RFC5280?

Hendrik

> I'm digging into this a bit deeper, and I see that CMS attributes are being used.
> The localKeyId defined in PKCS#9 is being used as a CMS attribute.
> 
> Russ
> 
> 
> 
> > Right now, the CMP Update document is importing Attribute from RFC 5652.
> It could also import Attribute from RFC 5280.  The two have the same syntax,
> but I believe that the use of Attribute is about naming attributes for the subject
> name in the certificate.  In the pyasn1-modules open source routines, the two
> kings of attributes are not mixed.  This means that at ASN.1 decode time, when
> an OID is encountered, only one of the lists will be searched to determine the
> associated type to proceed with the decode.  If no match is found, that open
> type is not decoded, and the application needs to handle that part of the
> message.  I do not know if other libraries have this issue or not.
> >

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 07:59:00 -0400

Hendrik:

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1

shows that RFC 4210 has the information about the assignment for id-regCtrl-altCertTemplate.

Russ

> On Jul 23, 2021, at 2:57 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 07:59:59 -0400

Hendrik:

I withdraw my suggestion.  The IMPORT from CMS will work perfectly in this case.

Russ

> On Jul 23, 2021, at 3:00 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 23 Jul 2021 12:35:16 +0000

OK, I had the wrong reference :-)
http://oid-info.com/get/1.3.6.1.5.5.7.5.1.7

I propose to add the definition as additional Section in CMP Updates and also refer to RFC 4212.

Hendrik

> Von: Russ Housley <[email-masked]>
> 
> Hendrik:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ian
> a.org%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xhtml%23smi-numbers-
> 1.3.6.1.5.5.7.5.1&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%
> 7C33b217dc68654cff6f0408d94dd14547%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637626383477384347%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 1000&amp;sdata=DlIJe770gU0uRTVgEXxSv1Ysa4uD2LHN%2Bq%2FLznazmOg%3
> D&amp;reserved=0
> 
> > You are right, id-regCtrl-altCertTemplate is not defined in the ASN.1 module in
> RFC 4210. RFC 4210 mentions id-regCtrl-altCertTemplate only in Appendix C.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.broc
> k
> >
> haus%40siemens.com%7C33b217dc68654cff6f0408d94dd14547%7C38ae3bcd9
> 5794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637626383477384347%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7
> >
> C1000&amp;sdata=%2F5WDzk47ngRwxj%2Fb2EXaiktrOks0%2BtIsOEujBkf54RI%
> 3D&a
> > mp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 09:10:31 -0400

Okay.  That seems like a good way forward.

Russ

> On Jul 23, 2021, at 8:35 AM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 11:00:39 -0400

To do this following the conventions in RFC 5912 for Appendix A.2, several changes are needed:

(1) Import SingleAttribute{} from PKIX-CommonTypes-2009:

   AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE
   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)}

(2) Import RegControlSet from PKIXCRMF-2009:

   CertTemplate, PKIPublicationInfo, EncryptedKey, CertId,
       CertReqMessages, Controls, RegControlSet, id-regCtrl
   FROM PKIXCRMF-2009
       { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-crmf2005-02(55) }

(3) Define AttributeTypeAndValue based on the imported SingleAttribute{}:

   AttributeTypeAndValue ::= SingleAttribute{{ ... }}

(4) Define an ATTRIBUTE for each of the controls:

   ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet |
      regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... }

   regCtrl-altCertTemplate ATTRIBUTE ::=
      { TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate }

   id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 }

   regCtrl-algId ATTRIBUTE ::=
      { TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId }

   id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 }

   AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}}
   -- SHALL be used to specify suported algorithms other than RSA

   regCtrl-rsaKeyLen ATTRIBUTE ::=
      { TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen }

   id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 }

   RsaKeyLenCtrl ::= INTEGER
   -- SHALL be used to specify suported RSA key lengths

The changes in Appendix A.1 are more straightforward:

(1) Import AttributeTypeAndValue from CRMF (RFC 4211):

       CertTemplate, PKIPublicationInfo, EncryptedKey, CertId,
       CertReqMessages, Controls, AttributeTypeAndValue, id-regCtrl
              FROM PKIXCRMF-2005 -- {iso(1) identified-organization(3)
              -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)
              -- id-mod(0) id-mod-crmf2005(36)}

(2) Define the controls:

   id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 }
   AltCertTemplate ::= AttributeTypeAndValue

   id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 }
   AlgIdCtrl ::= AlgorithmIdentifier
   -- SHALL be used to specify suported algorithms other than RSA

   id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 }
   RsaKeyLenCtrl ::= INTEGER
   -- SHALL be used to specify suported RSA key lengths

Russ

> On Jul 22, 2021, at 5:40 PM, Russ Housley <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 23 Jul 2021 15:49:31 +0000

Russ

There is further ASN.1 Syntax specified in RFC 4212, see sections 2.1, 2.2, and 4. 
The additional OIDs, like id-acTemplate for attribute certificates (section 2.1) and id-openPGPCertTemplateExt for PGP certificates (Section 2.2), seem to be not registered at IANA so fare, right?
Should we also add theses definitions as well as the updated definition of CMPCertificates and CertificateChoices (Section 4) to the ASN.1 modules in CMP Updates, or is it sufficient to introduce id-regCtrl-altCertTemplate?

Hendrik

> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Foid-i
> >
> nfo.com%2Fget%2F1.3.6.1.5.5.7.5.1.7&amp;data=04%7C01%7Chendrik.brockh
> a
> >
> us%40siemens.com%7Cb85fe967ae8846d4434308d94ddb6965%7C38ae3bcd95
> 794fd4
> >
> addab42e1495d55a%7C1%7C0%7C637626427024693425%7CUnknown%7CTWF
> pbGZsb3d8
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1
> >
> 000&amp;sdata=UPI9LQKd7qSenZZQ9ztuNyQgrRSv2UmoJ92PHDdBOQk%3D&a
> mp;reser
> > ved=0
> >
> >> shows that RFC 4210 has the information about the assignment for
> >> id-regCtrl- altCertTemplate.
> >>
> >> Russ
> >>
> >>
> >>> IANA refers to RFC 4212 as source for id-regCtrl-altCertTemplate,
> >>> but RFC
> >> 4212 does not have an ASN.1 module.
> >>>
> >>> Hendrik
> >>>
> >>>> I was just looking at RFC 4210, and the body of the document talks
> >>>> about
> >> this:
> >>>>
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
> >>>> ww
> >>>> .ietf
> >>>>
> >>
> haus%40siemens.com%7Cb85fe967ae8846d4434308d94ddb6965%7C38ae3bcd
> 95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637626427024703415%7CUnknown%7CT
> WFpbGZsb3
> >
> C1000&amp;sdata=f6vDIMeRieb1skIzvsnwLsSJs4%2FsiCJIPdqr8rFGcOU%3D&am
> p;r
> > eserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 23 Jul 2021 16:02:22 +0000

Russ

Manny thanks for this input. All changes are noted down for the next update.

Hendrik

> us%40siemens.com%7C09ae49489ad74b67007408d94deaafd0%7C38ae3bcd95
> 794fd4addab42e1495d55a%7C1%7C0%7C637626492641265550%7CUnknown%
> CJXVCI6Mn0%3D%7C1000&amp;sdata=QUdDw1tcB8oVQekFWTuPL%2F3QR8pR
> akf60rMPKf6MrUs%3D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 13:13:45 -0400

Hendrik:

You are correct; the registration controls used in RFC 4212 do not appear in the IANA registries.  I'll take the action to get them added.  I do not think that we need to burden th CMP Updates document with these OIDs.  Instead, it is probably better to do an update to RFC 4212 that provides the IANA registrations and an ASN.1 module.

Russ

> On Jul 23, 2021, at 11:49 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Jul 2021 15:13:15 -0400

Hendrik:

I just realized that the tags used in Section 4 of RFC 4212 conflict with RFC 5652, which says:

      CertificateChoices ::= CHOICE {
       certificate Certificate,
       extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
       v1AttrCert [1] IMPLICIT AttributeCertificateV1,       -- Obsolete
       v2AttrCert [2] IMPLICIT AttributeCertificateV2,
       other [3] IMPLICIT OtherCertificateFormat }

      OtherCertificateFormat ::= SEQUENCE {
        otherCertFormat OBJECT IDENTIFIER,
        otherCert ANY DEFINED BY otherCertFormat }

RFC 4212 proposes the use of tag [3] for OpenPGPCert.

I guess no one has really implemented RFC 4212, otherwise this conflict would have come to light earlier.

I'll keep the action to get the OIDs added to the IANA registry, but I do not want to produce an ASN.1 module that will conflict with RFC 5652.

Russ

> On Jul 23, 2021, at 1:13 PM, Russ Housley <[email-masked]> wrote:
> 
> Hendrik:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 26 Jul 2021 06:05:29 +0000

Russ

Thanks for checking.

> have come to light earlier.

We also do not implement RFC 4212.

> 
> I'll keep the action to get the OIDs added to the IANA registry, but I do not want
> to produce an ASN.1 module that will conflict with RFC 5652.

I am not that expert of CMC. If the conflict is not easy to solve, I am with you.
But when doing an update of RFC 4212 for OID registration, it would be nice to reach consistency of both RFCs.
Would it be possible to refer to RFC 5652 and specify how to use the OtherCertificateFormat sequence to carry OpenPGPCert?

Hendrik

> > You are correct; the registration controls used in RFC 4212 do not appear in
> the IANA registries.  I'll take the action to get them added.  I do not think that
> we need to burden th CMP Updates document with these OIDs.  Instead, it is
> probably better to do an update to RFC 4212 that provides the IANA
> registrations and an ASN.1 module.
> >
> > Russ
> >
> >
> >> The additional OIDs, like id-acTemplate for attribute certificates (section 2.1)
> and id-openPGPCertTemplateExt for PGP certificates (Section 2.2), seem to be
> not registered at IANA so fare, right?
> >> Should we also add theses definitions as well as the updated definition of
> CMPCertificates and CertificateChoices (Section 4) to the ASN.1 modules in CMP
> Updates, or is it sufficient to introduce id-regCtrl-altCertTemplate?
> >>
> >> Hendrik
> >>
> >>
> >>>> I propose to add the definition as additional Section in CMP
> >>>> Updates and also
> >>> refer to RFC 4212.
> >>>>
> >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> www
> >>>>> .ian
> >>>>>>> I was just looking at RFC 4210, and the body of the document
> >>>>>>> talks about
> >>>>> this:
> >>>>>>>
> >>>>>>> This control does not appear in the ASN,1 module, even though
> >>>>>>> RFC
> >>>>>>> 4210 is the source of this definition.
> >>>>>>>

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Jul 2021 10:35:48 -0400

> Would it be possible to refer to RFC 5652 and specify how to use the OtherCertificateFormat sequence to carry OpenPGPCert?

That is not my plan.  My plan i just to get the OIDs in the IANA registry.

There is a way to implement in CMC if there is interest in doing so.  Without that energy from interested people, I think that is all that should be done now.

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 26 Jul 2021 14:59:43 +0000

Russ

That is also fine with me.

Hendrik

> Gesendet: Montag, 26. Juli 2021 16:36
> An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
> Cc: LAMPS WG <[email-masked]>
> >> I guess no one has really implemented RFC 4212, otherwise this
> >> conflict would have come to light earlier.
> >
> >> I'll keep the action to get the OIDs added to the IANA registry, but
> >> I do not want to produce an ASN.1 module that will conflict with RFC 5652.
> >
> > Would it be possible to refer to RFC 5652 and specify how to use the
> OtherCertificateFormat sequence to carry OpenPGPCert?
> 
> There is a way to implement in CMC if there is interest in doing so.  Without that
> energy from interested people, I think that is all that should be done now.
> 
> Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Jul 2021 15:36:31 -0400

> That is not my plan.  My plan i just to get the OIDs in the IANA registry.

https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7299-update/ <https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7299-update/>

Here is the very short and straightforward Internet-Draft to get the OIDs into the IANA registry.

Since I am the author, Tim will make all consensus calls.

Russ