Add description on raVerified to Section 5.2.8

[HBrock]

As @primetomas proposed: Additional: In section 4.3 I think it's good to explicitly call out raVerified POP in a subsection. It is quite commonly used. It is mentioned in 5.1.1.3 and 5.2.8.4 and deserves a description under 4.3 imho.

[HB] You are right, the raVerified POP method is only described briefly in Section 5.2.8.4. This text may be extended. Section 4.3 is describing which POP methods to uses for which key-types. Section 5.2.8 describes different POP structures and methods and is the more appropriate place describing raVerified. Currently an additional subsection for raVerified would not fit well into the existing structure of Section 5.2.8. But if we decide to restructure the section, it could nicely fit. To be honest, the current structure is a bit odd anyhow, but as it originates from RFC 2510, I tried to change as little as possible. A new structure could look like this: 5.2.8. Proof-of-Possession Structures 5.2.8.1 raVerified 5.2.8.2 POPOSigningKey Structure 5.2.8.3 POPOPrivKey Structure 5.2.8.3.1. Inclusion of the Private Key 5.2.8.3.2. Encrypted Certificate - Indirect Method 5.2.8.3.3. Challenge-Response Protocol – Direct Method 5.2.8.4. Summary of PoP Options

[ounsworth]

Just for comparison, the current section has this structure:

5.2.8. Proof-of-Possession Structures 5.2.8.1. Inclusion of the Private Key 5.2.8.2. Indirect Method - Encrypted Certificate 5.2.8.3. Direct Method - Challenge-Response Protocol 5.2.8.4. Summary of PoP Options

So you are instead laying out the sections based on ASN.1 structures, and putting protocol flows as a sub-level.

I think that works.

[primetomas]

I like that

[HBrock]

conclusion 26.02.2024 The following points should be covered in the explanatory paragraph:

• The RA MUST check the POP before using raVerified
• If the RA performs changes to the original request that breaks the POP provided by the EE
• If the RA request on behalf of an EE which provided the POP out-of-band
• In other cases the RA MAY use raVerified together with providing the original message containing the POP in generalInfo, otherwise it SHOULD NOT use raVerified

[HBrock]

@primetomas @johngray-dev @ounsworth What do you think about this text explaining the usage of raVerified?

Section 5.2.8.1 raVerified When using raVerified, the RA MUST check the proof-of-possession provided by the EE. It MAY use raVerified together with providing the original message containing the POP provided by the EE in the generalInfo field using the id-it-origPKIMessage, see Section 5.1.1.3. If the RA performs changes to a certification request received from an EE, where these changes break the POP provided by the EE, or if the RA requests a certificate on behalf of an EE which provided the POP out-of-band, the RA MUST use the raVerified choice. Otherwise, it SHOULD NOT use raVerified.

[primetomas]

As long as that description also work for i.e. RA generated smart cards. I guess you can interpret that as "the RA requests a certificate on behalf of an EE which provided the POP out-of-band", if you interpret the EE's PoP as the smart card printer being local :-)

[HBrock]

Good point. I would regard smart card production as 'on-behalf' where either the RA can provide a POP as it has access to the private key (either as it generates the key pair outside the smart card, or because it could make use of the private key on the smart card), or the POP is provided out-of-band due to organizational measures (as you suggested). Only in the latter case usage of raVerified is needed.

[HBrock]

@primetomas David and I rephrased the section to address your point. What do you think?

5.2.8.1. raVerified

An EE MUST NOT use raVerified. If an RA performs changes to a certification request breaking the provided proof-of-possession (POP), or if the RA requests a certificate on behalf of an EE and cannot provide the POP itself, the RA MUST use raVerified. Otherwise, it SHOULD NOT use raVerified. When introducing raVerified, the RA MUST check the existing POP, or it MUST ensure by other means that the EE is the holder of the private key. The RA MAY provide the original message containing the POP in the generalInfo field using the id-it-origPKIMessage, see Section 5.1.1.3, enabling the CA to verify it.

[primetomas]

Sounds good!