Why is CAKeyUpdAnnContent not identical to RootCaKeyUpdateContent?

[primetomas]

These are identical data structures for the same use case, isn't it?

[HBrock]

CAKeyUpdAnnContent is the content type for an announcement message from the CA/RA to the EE, see Section 5.3.13 and Section 5.3.19.5. I cannot say, why it is available as ckuann and as genm value.

RootCaKeyUpdateContent was added by RFC 9480 for genm/genp message pair. The genm of type id-it-rootCaCert offers the EE a request message to request a root CA key update from the RA/CA, see Section 5.3.19.15 and RFC 9483 Section 4.3.2.

In contrast to CAKeyUpdAnnContent, in RootCaKeyUpdateContent the newWithOld and OldWithNew link certificates are optional and can be omitted, depending on the EE needs.

[HBrock]

Typically the number of certificates contained in a message rule the size of the message. This becomes even more crucial with PQC algorithms. Therefore, we want to offer a message that does not need to transfer certificates that are not needed. We think, in many cases the oldWithNew certificate is not required, therefore, we wanted to have it optional. For flexibility, we also defined newWithOld as optional, but RFC 9483 required to use it. So the message offers full flexibility, but the profile limits it to the main use case.

[primetomas]

Exactly, sorry for the brief description. I know the differences. When introducing CMPv3 why not update CAKeyUpdAnnContent as well?

[HBrock]

You are right, we could have changed CAKeyUpdAnnContent, but this would have complicated the version management.

The design criteria for CMP Updates was to add what is needed for the Lightweight CMP Profile and not to break or change any existing functionality. We do not use any announcement messages in LCMPP. Therefore, we did not think about changing the content of outbound CA messages like ckuann or genm with id-it-caKeyUpdateInfo.

Are you aware of products making use of announcement messages? Do you think this is a change we should add to rfc4210bis?

[primetomas]

I'm not aware of any product that uses ckuann or genm with id-it-caKeyUpdateInfo. So not updating will not change any use case that I'm aware of. For future consistence (you never know who gets into which part of the spec) it would be worth changing it imho. Since I don't know of anyone using it, I also don't know that anyone would be hurt by it, and it would make the specification more consistent and easier to grasp/harder to make mistakes.

[HBrock]

Thank you. I see your point.

If we want to align this, I would propose to define that ckuann uses RootCaKeyUpdateContent with CMP v3 instead of changing the ASN.1 definition of CAKeyUpdAnnContent. I am uncertain how to change the ASN.1 syntax of CAKeyUpdAnnContent keeping backward compatible.

With genm the CA could technically already use id-it-caKeyUpdateInfo. This would need to be changed in Section 5.3.19.5.

What do you think?

[DDvO]

Yeah, we could cleanly modify ckuann to use RootCaKeyUpdateContent (instead of CAKeyUpdAnnContent) by requiring this to be indicated with CMPv3 in the message header, and deprecate CAKeyUpdAnnContent.

[primetomas]

Agree, that sounds like a neat solution.

[HBrock]

This will also affect Appendix D.4. I would propose to also use RootCaKeyUpdateContent there and allow CAKeyUpdAnnContent only if backward compatibility is required. Should we keep the requirement of oldWithNew and newWithOld beeing both present, or should be change anything there?

[primetomas]

I think we should make them optional as for RootCaKeyUpdateContent. That makes CMP more adaptable to different use cases.

[HBrock]

You are right, they are optional in RootCaKeyUpdateContent. The question is, shall we change the profile in Appendix D.4. My proposal would be to at least require setting newWithOld in the profile as we also did in RFC9483 Section 4.3.2. But as said above, I am not aware of the intended use case behind this PKI management operation. Therefore, oldWithNew may also be required.

[primetomas]

Appendix D.4 looks very much like 5.3.19.5 to me. "via some transport mechanism" in D.4, sounds like "for example the one described in 5.3.19.15, or another method.

[HBrock]

The point is that Section 5.3.19.15 specifies the fully flexible ASN.1 structure and Appendix D.4 is supposed to be a profile providing a clear guidance what options to use and what not. If we now say, newWithOld and oldWithNew are optional, it a repetition of the content from before and no profiling. Therefore, I asked for the use case behind Appendix D.4 to decide on what option is needed. As we do not know the use case, we could use the profiling like in RFC 9483 saying the newWithOld is required and oldWithNew is optional.

[primetomas]

Imho D.4 isn't much of a profile. To me it looks like Appendix D just must have a section for every message of the specification, even if it doesn't add any, or much, information. It doesn't really add any new information that is not already in 5.3.19.15, 5.3.13 and 5.3.19.5. Not sure what profile guidance information D.4 adds here for implementors? Appendix D.3 doesn't give much guidance either imho. Changing "present" to "optional" in D.4 at least makes it consistent across the document. D.4 doesn't describe any specific use case or processing, so what harm can it do?

[HBrock]

Sorry, probably did not explain my point properly.

In CAKeyUpdAnnContent there are no options. There is no profiling possible. If we introduce RootCaKeyUpdateContent instead, we also introduce options in the syntax. Typically a profile explains how to handle optional fields depending on the use case the profile addresses. I wanted to clarify, if the we want to state how to handle these options in the profile defined in Appendix C and D.

As we do not know what uses case drives the profile in Appendix D.4, there three potential was to go forward

• both optional fields must be used (this is the status quo as of RFC 4210)
• only newWithOld must be set and oldWithNew is optional (this is in line with RFC 9483)
• both fields are optional (this is what you propose)

[HBrock]

I prepared a PR implementing this change. Does that fit?

While doing the changes, I noticed that I had to introduce a new PKIBody choice "ckuannV3" of type RootCaKeyUpdateContent for use with CMP V3. For backward compatibility I had to keep ckuann unchanged for use with CMP V2.

[HBrock]

I updated the PR (2c87ff1bfda862d4182398e2d9cba3c3e4a112a9) introducing

CAKeyUpdContent ::= CHOICE {
    cAKeyUpdAnnV2      CAKeyUpdAnnContent, -- deprecated
    cAKeyUpdAnnV3  [0] RootCaKeyUpdateContent
}

to ease backward compatibility.

@primetomas, what do you think. Is this what you had in mind?

[primetomas]

That sounds great. I can close this issue.