Removing normative language from Section 4.2.2

[HBrock]

As @primetomas proposed:

1. Section 4.2.2.1 describes it as mandatory that the CA can send a CMP message to the end entity directly. I think this is an extremely rare case, and very hard to interpret. CAs can virtually never make an on-line connection to end entities, so this scheme assumes an out-of-band deliver of the CMP message, which is hard to envision imho. At least without stating that this is outside of the scop. The most basic cases I know of always involve some RA that initiates the request to the CA. This is confusing to me.

[HB] I fully support your point. As you know, RFC 9483 also addresses PKI Management Operations between RA and CA. But as I read Section 4.2.2 the only mandators scheme is specified in Section 4.2.2.2. The Centralizes Scheme specified in Section 4.2.2.1 is optional. But I can envision this scheme for example in a factory with a local CA providing key generation and certificate issuance on behalf of the device. But you are perfectly right, this is not a scenario CMP would be used for. I see Section 4.2 more as a first illustration how enrollment could look like. As there is the profile for enrollment of person-certificate in the Appendix and the profile for machine-to-machine enrollment in RFC 9483, it would be fine removing normative language from Section 4.2 completely, if the WG agrees.

[primetomas]

I support removing the normative language in 4.2.2. This can be handled in profiles, and is in many cases already. I.e. 3GPP 33.310, Lightweight CMP profile, Unisig ERTMS, etc.

[HBrock]

@johngray-dev @ounsworth @DDvO What do you think of removing normative text from Section 4.2.2 and leave this to the respective profiles?

[johngray-dev]

Yes I agree. Our end-entities can connect to our CA, but it is always end-entity driven. The keys are generated at either the CA, the client or 3rd party. I agree the text only says 4.2.2.2 is mandatory, but I see how it can be confusing since it is all under 4.2.2 titled "Mandatory Schemes". Maybe just changing the title of 4.2.2 to "Registration / Certification Schemes", take out the normative language, then then add the MUST in 4.2.2.2 directly would make it more clear.

[HBrock]

As there are several profiles of CMP available, like

• Appendix D and E of RFC 4210,
• RFC 9483,
• 3GPP TS 33.310, and
• UNISIG Subset 137.

Therefore, RFC 4210 developed more to a framework and a generic protocol specification. RFC 5280 also defines the X.509 certificate and CRL content and path validation mechanism in a generic manner, and there are many protocol specific profiles available.

When looking at RFC 4210 there are more section using normative language that may hinder claiming compliance when using one of the above listed profiles or when using CMP with a proprietary profile. If we support the development of rfc4210bis to such a generic certificate management protocol framework, I feel like, we must also also look at other sections, e.g., Section 6, and reconsider the usage of normative language there. Currently this was out-of-scope of the tasks we got from the LAMPS WG.

[DDvO]

I agree the text only says 4.2.2.2 is mandatory, but I see how it can be confusing since it is all under 4.2.2 titled "Mandatory Schemes". Maybe just changing the title of 4.2.2 to "Registration / Certification Schemes", take out the normative language, then then add the MUST in 4.2.2.2 directly would make it more clear.

I support this and am confident that the WG will be fine with this. It is essentially just an editorial change that prevents needless confusion.

[HBrock]

The following slide was presented at IETF 119:

Remove normative language from Section 4.2.2, by Tomas Gustavsson

There are various profiles that specify initial registration and certification in much more detail, e.g., Appendix C and D, RFC 9483, 3GPP TS 33.310, UNISIG Subset 137. Therefore, today rfc4210bis is more of a framework and Section 4.2 is more a guidance.

Option 1: Adapt headline of Section 4.2.2 to avoid confusion and keep text as of RFC 4210 retaining backward compatibility. Option 2: Adapt headline of Section 4.2.2 to avoid confusion and remove normative language. Option 3: Rework Section 3, 4, and 6 to modernize it and remove normative where not needed.

[HBrock]

With V10 the following changes were addresses:

• Implemented some minor editorial changes modernizing the text in Section 3, 4, and 5.2.8 as proposed during IETF 119, without changing normative language.
• Added to Section 4.2.2 two ToDos for further discussion, based on the comment from Tomas Gustavsson as presented during IETF 119.

I will address proposals for the remaining ToDos on the LAMPS list.