IETF conflict review for draft-turner-sodp-profile
conflict-review-turner-sodp-profile-00

Thanks for the changes in flight to clarify how HTTP's Accept header
field is used to indicate PAL content types.

Section 1.1

     o CNSA-related (Commercial National Security Algorithm) drafts
       [RFC8603], [RFC8755], [RFC8756], and
       [ID.cnsa-tls-profile]. The profile defined herein does not
       support RSA-based or DHE-based key establishment algorithms.

If we're going ECC+AES+SHA384-only, it might be more readable to just
say that.

Section 1.2

     o Section 2 specifies the version of ASN.1 (Abstract Syntax
       Notation One) version used.

nit: double "version".

Section 1.3

(side note) I'm kind of curious where (if anywhere) a Kerberos KDC or
similar entity would fit into the KTA hierarchy.

   distribute PKI-related information through the /cacerts, /crls,
   /eecerts, /fulcmc, /simpleenroll, /simplereenroll, /csrattrs EST and
   EST extension services.

nits: s/fulcmc/fullcmc/; s%/csrattrs% and /csrattrs%

Section 3.2

   TLS implementations are configured as specified in
   [ID.cnsa-tls-profile]; the notable exceptions are that RSA-based and
   DHE-based key establishment algorithms are not used.

So that puts us at ECDHE-only?  Might as well just say so.

Section 3.6.3

   CSRs follow the specifications in Section 5.1 of [RFC8756],
   with two exceptions.  First, the Change Subject Name and
   the POP Link Witness V2 attributes, which are CMC-specific
   requirements do not apply.  Second, RSA-based algorithms are not
   used.

Section 4.2 of 8756 looks more relevant than Section 5.1 does.

   Client requests include the tls-unique value in the challenge-

Sigh, tls-unique.

Section 3.6.6

   PFXs [RFC7292] are exchanged using both password privacy mode and
   integrity password mode.  The PRF algorithm for both the PBES2 and
   PBMAC1 is HMAC-SHA-384 and the PBES2 encryption scheme is AES-256.

I see PBES2 needing a KDF function, but is that the same as the PRF
algorithm?

Section 3.6.9

   Clients that claim to support SODP-interoperation will be able to
   process the following messages from a SODP server: additional
   encryption and origin authentication ([RFC8295], Section 5); server-
   provided Symmetric Key Content Type [RFC6032] encapsulated in an
   Encrypted Key Content Type using the EnvelopedData choice [RFC6033]
   with a SOA certificate that includes the CMS Content Constraints
   extension (see Section 7.1).

I see that a previous reviewer noted some disparity between the
introduction's "need not implement all of the interfaces specified
herein [...] free to choose which interfaces" and some more specific
requirements in the text; this seems to be another such instance.

       /serverkeygen/return is not used at this time.

This is the /symmetrickeys section; is this statement still relevant?

Section 4.1

   Clients use only the HTTPS-based transport; the TLS implementation
   and configuration is as specified in [ID.cnsa-tls-profile]; the
   notable exceptions are that RSA-based and DHE-based key establishment
   algorithms are not used.

(same as above)

Section 5

   Issuer and subject names are composed of only the following naming
   attributes: country name, domain component, organization name,
   organizational unit name, common name, state or province name,
   distinguished name qualifier, and serial number.

Just to confirm: this is the serial number name component, distinct from
the issuer's serial number for tracking its issued certificates?

   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.

This seems to be compatible with RFC 5280, but is a little surprising to
me, since it seems to needlessly risk collisions when a digest of the
full public key could incorporate more entropy into the SPKI.

[both of these comments have relevance in the later sections as well]

Section 7

I assume it is deliberate that nothing is mentioned about
extendedKeyUsage?