Update Sections 4.4 and 5.2.5 moving outdated text to an appendix

[HBrock]

@primetomas proposed:

2. Section 4.4 on root CA key update seems very verbose. It discusses the odd case of CA rollback to great lengths, which I'm sure is extremely rare. We discussed during the period of RFC9480, about the need for OldWithNew, which is why RFC9480 have both NewWithOld and OldWithNew as optional in 5.3.19.15. I don't think it is good to bring that back here in the form of: "Thus, when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld, OldWithNew, NewWithOld, and NewWithNew).". Using an x.500 directory as reference I don't think is a good one. • Keeping these optional enables us to cut down on the verbose wording quite some. You can basically remove the whole section 4.4.1, or shorten it substantially. • It would be good if section 4.4 gave more advice on the standard use case of CA Renewal • Section 4.4.2.x seems to assume an LDAP directory. Also nothing that is common, I don't think the CMP draft should specify which LDAP attributes to look up ("Look up the cACertificate attribute in the repository"). Either CMP have a mechanism to distribute new certificates, or it's out of scop and we can remove those words. • The section assumes support for X.509 v1, without extensions. I don't think this is appropriate. CMPv3 makes extensive use of extensions in the specification so assuming X.509v3 with extensions I think would be better. CMPv3 will not work without extensions anyhow.

[HB] I absolutely support your point. I see Section 4.4 more as a historic and explanatory section. I cannot say, if it has any relevance today. But I know that at least Section 4.1.3 of RFC 7030 is referring to the CA rollover model of CMP pointing to Section 4.4 of RFC 4210. Therefore, I was hesitating to change anything further on this section. Finally, this section does not use normative language (except twice where it is not critical). Therefore, I do not see the need for implementing this as specified here for RFC compliance. But as said, I am open for proposals how to update the section to express the issues you described. Maybe we can also move historic text of this section to an Appendix if people do not want to drop it completely. Could you contribute text for an updates Section 4.4?

@primetomas proposed:

4. Section 5.2.5 should be removed imho. It says it is out of scope, why define ASN.1 data structures for something that is out of scope of the document? I think it's right to keep it out of scope, but then the whole section can be removed.

[HB] I do not know, why this section and the ASN.1 definition were added to the document, but they were already part of RFC 2510 :-) I could imagine moving this section together with parts of Section 4.4 to an appendix. Could you address this in your proposal for an updated Section 4.4 as well?

[primetomas]

Created PR with proposed changes

[HBrock]

Thank you for your proposal. I saw, you that you updated Section 4.4 and Section 4.4.1 and removed Section 4.4.2. Section 5.2.5 is unchanged. See the diff Section 4.4 old.diff.html.pdf.

When checking https://datatracker.ietf.org/doc/rfc4210/referencedby/, I identified the following documents referring to Section 4.4 of RFC 4210:

• draft-ietf-anima-constrained-voucher
• RFC 8994
• RFC 8649
• RFC 7030
• RFC 6024
• RFC 5280 Therefore, I am uncertain if we should change/delete this much text.

@johngray-dev @ounsworth Do you have any further thoughts or proposals?

[primetomas]

Should we keep the section but state that it changed and moved to Appendix?

[HBrock]

I would propose to present the proposal to the LAMPS WG during next IETF and ask for their guidance.

[johngray-dev]

The text as it is in there makes perfect sense to me, and essentially describes how our CA works for doing its CA key updates (for probably the past 20+ years).

Current Text: The basis of the procedure described here is that the CA protects its new public key using its previous private key and vice versa. Thus, when a CA updates its key pair it must generate two extra cACertificate attribute values if certificates are made available using an X.500 directory (for a total of four: OldWithOld, OldWithNew, NewWithOld, and NewWithNew).

Proposed Change: RFC4210 describes extra certificates used by a CA to protect its new public key. This method has been shown to be very use case specific and no assumptions are done on this aspect and RootCaKeyUpdateContent is updated to specify the extra fields as optional.

I don't know what is meant by "This method has been shown to be very use case specific"? How has it been shown to be use-case specific? The existing text essentially explains an example of how root CA certificate management works. I guess it is only giving one specific way of doing a CA key update but it is the use case I believe makes the most sense. If you don't make link certificates then existing clients will have to have their trust stores manually updated with the new CA root, or some alternate out of band means for them to retrieve and trust the new root would be required. The link certificates allow them to temporarily verify there is a link of trust between the original trusted root and the new root, and therefore trust the updated root. I guess not everyone needs to use link certificates, but then CA updates are just so much more painful.

So if these CA key management methods aren't written in another RFC, then I think having it is in the scope of this document, it is CMP, and managing a CA's Certificate management is in scope right? If we want to cover other use cases like the non-link cert method, or various out-of-band methods then I would be okay with moving this to an appendix, and at least keep this link cert method and why its useful, and the non-link cert method and its requirement of out-of-band updates (which we can say it out of scope). Then at least the information is captured.

So yes, probably this needs to be mentioned in a LAMPS update

[primetomas]

Thanks for sharing your experience.

1. What I meant with "This method has been shown to be very use case specific" is that there are other standards (some using CMP) that performs CA updates in different ways.Two specific examples:

   • Link certificates using NewWithOld is common, in ICAO 9303 it is mandated. ICAO 9303 does not use NewWithOld however.
   • 3GPP 33.310 relies on CMP, but don't specify use of link certificates at all, and implementation I'm aware of don't use it. I do agree that link certificates as used in ICAO 9303 is useful for trust anchor update.

2. Most CAs do not use X.500 directories. It doesn't feel right that RFC4210bit mentions specific database technology.

While you can read 4.4 as it is only a discussion of an example method. This is not fully clear. Being under section 4 that is called "Assumptions and Restrictions".

The fact that the link certificates are now Optional in CMPv3 makes me want to update this section, because the 4.4 discussion is not written with this optionality in mind.

About references (thanks for digging them up Hendrik):

• RFC7030 references it as a defined SHOULD requirement, but no client has asked us about link certificates in EST yet. Being a SHOULD and the optionality in CMPv3 I'd expect different use case can arise. An updated section 4.4 could be helpful
• RFC8994 references it much more loosely than RFC7030. An updated section 4.4 incorporating the CMPv3 optionality would suffice to fulfill this reference.
• I can't find the reference in RFC5280.
• RFC8649 has it under Operational Considerations, so an updated section 4.4. should work there as well
• RFC6024 doesn't reference section 4.4 directly but RFC4210 in general so it's ok.
• draft-ietf-anima-constrained-voucher references it as a "mechanism described in RFC4210 Section 4.4" being a bit problematic, but could likely be ok with an updated section 4.4?

This discussion makes me want to keep it as section 4.4, but update it to

• introduce the Optionality of CMPv3
• remove specification of an X.500 directory (the specs referencing this section all specify distribution through their protocol instead of through a directory)
• Add something more about assumptions and restrictions. For example that CA subject DN change it a common, that old and new CAs may be on different systems, and that different use cases for the same protocol may have different restrictions and capabilities.
• remove the assumption on X.509v1 only certs
• potentially shorten it a bit, it's a quite long discussion section?

Could you agree with that approach?

[HBrock]

thanks for the lively discussion. I do not have the experience that you have regarding the variety of PKI usages. I only have my limited scope on the OT space. Therefor I may be a bit shy to change some of the old and mature text in 4210. I do not want to accidently break anything.

The fact that the link certificates are now Optional in CMPv3 makes me want to update this section, because the 4.4 discussion is not written with this optionality in mind. Section 5.3.19.15 offers a ASN.1 type with optional newWithOld and oldWithNew. This is to support also those entities that may not need the one or the other link certificate. this section says nothing about whether or not a CA should issue it for proper trust establishment in both directions.

I can't find the reference in RFC5280. RFC5280 refers to RFC 4210 in the Security Considerations saying: Detailed procedures for "CA key update" are specified in [RFC4210], where the CA protects its new public key using its previous private key and vice versa using two self-issued certificates.

RFC6024 doesn't reference section 4.4 directly but RFC4210 in general so it's ok. RFC 6042 refers to RFC 4210 with regard to in-band trust anchor update saying: Routine trust anchor rekey operations typically require similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) [RFC4210].

Generally speaking, I also think, theses references should not hinder updating Section 4.4. I also like Tomas proposals. Maybe we can leave LDAP as an example. As said before, I just do not fee comfortable with changing the content of this section due to my limited background on this section and therefore would need strong support by the LAMPS WG or others having this background.

[HBrock]

closed after merging PR #54