[lamps] CMSbis sections B.3, B.4, and C.1 - Re: WGLC for CMCbis

[David von Oheimb <[e-mail]>]

On 06.04.25 17:39, Russ Housley wrote:
> The authors believe that these documents are ready for publications as a Standards Track RFCs.
>
> The Internet-Drafts are here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5272bis/

I hadn't noticed this WGLC before yesterday, which is why I'm responding 
now on Easter Sunday, right before its end.

Good to see that CMCbis updates and (so far, partially) improves the 
parts on direct challenge-based POP of KEM keys.
I just had a close look at them, which are the sections 6.7, B.3, B.4, 
and C.1.
Some changes compared to RFC 5272 
<https://author-tools.ietf.org/iddiff?url1=rfc5272&url2=draft-ietf-lamps-rfc5272bis-03&difftype=--html> 
have been made on these, improving some issues while introducing some 
(mostly minor) mistakes.
For the examples in B.3 and B.3, so far all of their sloppiness (being 
incomplete and wrong in some details) has been retained.
See details including improvement suggestions below.

     David


1.

In 6.7, "the hash of" has been inserted in

          3.  Client decrypts the POP challenge using the private key 
that corresponds to the
               presented public key and sends *the hash of* 
the plaintext back to the server.

This is certainly an improvement over the original sentence, but still 
not really correct.
Should better be, e.g.,

          3.  Client decrypts the POP challenge using the private key 
that corresponds to the
               presented public key and uses it for computing a keyed 
hash value sent back to the server.

While being at this, I suggest making also

     The second deals with the decrypted challenge sent from the client 
to the server in Step 3.

more precise/correct, e.g., adapting it to

     The second deals with the value derived from the decrypted 
challenge sent by the client to the server in Step 3.


2.

In B.3, the statement

    The fact that a second round-trip is required is implicit rather than
    explicit.  The server determines this based on the fact that no other
    POP exists for the certification request.

appears wrong because the Message #1 contains the "keyEncipherment" 
choice with "subsequentMessage" in the "popo" field:

                popo
                  keyEncipherment
                    subsequentMessage

which already indicates the need for some form of encrypted POP. So 
please correct this statement or explain suitably.


3.

Regarding the sentence:

  For simplicity, it is assumed that the certification requester already has a signing-only certificate.

  * Any signing-capable cert/key, not just a signing-only cert, will
    work for the signature-based authentication of the CMC requests.
  * What if the requester or server has just a KEM certificate and thus
    cannot sign messages for their authentication?


4.

At least in B.3 and B.4, the syntax and descriptions of the requests 
(which are partly repeated in the responses) is sketchy.
Most of this has been simply taken over from RFC 5262, which has mostly 
the same deficiencies.
For instance, in

            reqSequence
              certRequest
                certReqId = 201
                certTemplate
                  subject = <My DN from my signing cert>
                  publicKey = My Public Key
                  extensions
                    {id-ce-keyUsage, keyEncipherment}
                    {id-ce-subjectPublicKeyIdentifier, 1000}
                popo
                  keyEncipherment
                    subsequentMessage

  * in "subject = <My DN from my signing cert>" (used several times),
    better leave out "from my signing cert"
    because in general the new cert will have a different subject than
    the one used to authenticate the request.
  * the field name "crm" (of type CertReqMsg) is missing between
    reqSequence and certRequest, and the name "certRequest" is wrong -
    it should read "certReq"
  * the "popo" field should not be at same level as "certTemplate", as
    it is a direct sub-field of "crm", not of certReq
  * the subsequentMessage is missing its integer value, which in this
    case must be 1 (for challengeResp, see
    https://www.rfc-editor.org/rfc/rfc4211.html#section-4.2)

Recall from sections 3.2.1.x:

      PKIData ::= SEQUENCE {
        ...
        reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,
        ...
      }

      TaggedRequest ::= CHOICE {
        ...
        crm               [1] CertReqMsg,
        ...
      }

      CertReqMsg ::= SEQUENCE {
        certReq   CertRequest,
        popo      ProofOfPossession  OPTIONAL, -- content depends upon key type
        regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

      CertRequest ::= SEQUENCE {
        certReqId     INTEGER,            -- ID for matching request and reply
        certTemplate  CertTemplate,       -- Selected fields of cert to be issued
        controls      Controls OPTIONAL } -- Attributes affecting issuance

5.

In the Response #1 (in both B.3 and B.4),

  * In recipientInfos.riid.issuerSerialNumber, "riid" is wrong and
    should read "rid".
  * Please mention in B.3 and B.4 that the 'y' in

eContent = <Encrypted value of 'y'> and witness <hashed value of 'y'> is 
the POP Proof Value as defined at the end of section 6.7.

  * Some hints on how to fill in the non-trivial"cms" field of type
    EnvelopedData maybe helpful.
  * The "Other certificates (optional)" may be confusing - please
    mention that these are only related to the signature of the response
    and do not already include the requested certificate, will be
    included only in the final response.
  * BTW, I doubt that it was a good design decision that the
    EncryptedPOP structure must repeat the whole request - the advantage
    mentioned in section 6.7 that the client does not strictly need to
    remember the request data comes with some downsides: the client
    either still needs keep a copy in order to check consistency with
    its request or needs to trust in the server not having altered it,
    and the larger KEM public keys may need to become in future, the
    bigger the waste. Would have been good to allow giving instead just
    the certReqId.

6.

Appendix C.1:

Concerning https://www.rfc-editor.org/errata/eid8137,
someone added to the Notes there: "'This has been fixed in RFC 6402"
but I do not see in RFC 6402 anything regarding No-Signatures as 
described in RFC 5272 Appendix C.1.

Good that the current CMCbis draft does extend "the hash" to "the SHA-1 
hash" as suggested,
but it does not add the proposed further sentence: "The hash value given 
by NoSignatureValue SHOULD be ignored."
Was this on purpose?

In section 1.5 is missing:

*  Merged [erratum8137]

7.

Section 1.5 and Appendix B (several occurrences):

id-ce-subjectPublicKeyIdentifier ->
id-ce-subjectKeyIdentifier


8.

Some (editorial) nits:

Abstract, Introduction, Appendices B.3 and B.4:

encryption only keys ->
encryption-only keys

Appendix B.3:

encryption only certificate ->
encryption-only certificate

"; the example below shows":

Complete or remove that incomplete sub-sentence.

round-trip ->
round trip

Appendix B.4:

encryption only cerrtificate ->
encryption-only certificate

Appendix C (intro):

are key	encapsulation mechanisms (KEM) are ->
are key	encapsulation mechanisms (KEM)


Appendix C.1:

it has two choices issuerAndSerialNumber or subjectKeyIdentifier. ->
it has two choices: issuerAndSerialNumber or subjectKeyIdentifier.