Subject: [lamps] dtaft-ietf-lamps-cmp-updates add section to introduce id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 10 Aug 2020 06:40:32 +0000

When working on the next update of the Lightweight CMP Profile, I was discussing the advantages of introducing the new OIDs for the support messages (id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate) together with their ASN.1 syntax already in CMP Updates.
I see two advantages:
1) The IDs can also be used outside of the use of the Lightweight CMP Profile
2) All changes and additions to the CMP ASN.1 module would be performed in one document only. The Lightweight CMP Profile would not need an additional ASN.1 module.

What is the opinion of the group?

This would be the additional section for CMP Updates and the respective ASN.1 Syntax of the new types.

2.7.  Update Section 5.3.19. - PKI General Message Content

Section 5.3.19 of RFC 4210 [RFC4210] describes examples InfoTypeAndValue to be used in general messages content. This document adds three additional sub-section to introduce new IDs id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate to the support messages as defined in [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4.
Add these new sub-sections at the end of this section with the following text.

2.3.19.14 CA Certificates

This MAY be used by the client to get the latest CA intermediate and issuing CA certificates.

   GenMsg:    {id-it 17}, < absent >
   GenRep:    {id-it 17}, CaCerts | < absent >

5.3.19.15. Root CA Certificates Update

This MAY be used by the client to get an update of an existing root CA Certificate.

   GenMsg:    {id-it 18}, < absent >
   GenRep:    {id-it 18}, RootCaKeyUpdate | < absent >

Note: In contrast to CAKeyUpdAnnContent, this type offers omitting newWithOld and oldWithNew in the GenRep message, depending on the needs of the EE.

5.3.19.16. Certificate Request Template

This MAY be used by the client to get a template with parameters for a future certificate request operation.

   GenMsg:    {id-it 19}, < absent >
   GenRep:    {id-it 19}, CertReqTemplateValue | < absent >

Addition to ASN.1 module in Appendix A:

   id-it-caCerts OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 17}
       CaCerts ::= SEQUENCE OF CMPCertificate

   id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 18}
       RootCaKeyUpdate ::= SEQUENCE {
           newWithNew       CMPCertificate
           newWithOld   [0] CMPCertificate OPTIONAL,
           oldWithNew   [1] CMPCertificate OPTIONAL
       }

   id-it-certReqTemplate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 19}
       CertReqTemplateValue ::= SEQUENCE {
           certTemplate           CertTemplate,
           rsaKeyLen                 INTEGER        OPTIONAL
       }

Hendrik

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 12 Aug 2020 06:13:41 +0000

Hi Hendrik,

> From: Spasm <[email-masked]> On Behalf Of Brockhaus, Hendrik
> Sent: Montag, 10. August 2020 08:41
> Subject: [lamps] dtaft-ietf-lamps-cmp-updates add section to introduce id-it-
> caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate
> 
> When working on the next update of the Lightweight CMP Profile, I was
> discussing the advantages of introducing the new OIDs for the support
> messages (id-it-caCerts, id-it-rootCaKeyUpdate, and id-it-certReqTemplate)
> together with their ASN.1 syntax already in CMP Updates.
> I see two advantages:
> 2) All changes and additions to the CMP ASN.1 module would be performed
> in one document only. The Lightweight CMP Profile would not need an
> additional ASN.1 module.
> 
>From a Lightweight CMP perspective I would support the takeover into the CMP updates document. From my understanding the change is independent of the Lightweight CMP profile and could be usable for other documents, that would like to refer to CMP directly. Also as the Lightweight Profile is intended to reduce the options in CMP. Introducing new OIDs and respective ASN.1 Modules actually goes beyond the profiling from my point of view. Therefore, I (also as co-author of Lightweight CMP) would be in favor of moving it to the CMP updates document . 

Best regards
Steffen

> Section 5.3.19 of RFC 4210 [RFC4210] describes examples InfoTypeAndValue
> to be used in general messages content. This document adds three
> additional sub-section to introduce new IDs id-it-caCerts, id-it-
> rootCaKeyUpdate, and id-it-certReqTemplate to the support messages as
> defined in [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4.
> Note: In contrast to CAKeyUpdAnnContent, this type offers omitting
> newWithOld and oldWithNew in the GenRep message, depending on the
> needs of the EE.
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm