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

The following approval message was sent
From: The IESG
To: draft-turner-sodp-profile@ietf.org,
    Adrian Farrel ,
    rfc-ise@rfc-editor.org
Cc: iana@iana.org,
    IETF-Announce ,
    The IESG
Subject: Results of IETF-conflict review for draft-turner-sodp-profile-07

The IESG has completed a review of draft-turner-sodp-profile-07 consistent
with RFC5742.

The IESG has no problem with the publication of 'The SODP (Secure Object
Delivery Protocol) Server Interfaces: NSA's Profile for Delivery of
Certificates, CRLs, and Symmetric Keys to Clients'
as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in the
LAMPS WG, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-turner-sodp-profile/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-turner-sodp-profile/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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?

[Ballot comment]
To remove confusion about HTTP header usage, please make this edit in Section 3.1

OLD:
  Clients include an HTTP Accept header with each HTTP GET request to
  indicate the PAL Package Types supported ([RFC8295], Section 2.1.1).

NEW
  Per Section 2.2 of [RFC8295], clients indicate the format ("application/xml" or "application/json") of the PAL information ([RFC8295], Section 2.1.1) via the HTTP Accept header.

[Ballot comment]
To remove confusing about HTTP header usage, please make this edit in Section 3.1

OLD:
  Clients include an HTTP Accept header with each HTTP GET request to
  indicate the PAL Package Types supported ([RFC8295], Section 2.1.1).

NEW
  Per Section 2.2 of [RFC8295], clients indicate the format ("application/xml" or "application/json") of the PAL information ([RFC8295], Section 2.1.1) via the HTTP Accept header.

[Ballot comment]
[Only sending mail to the IESG since my review is incomplete]

Section 3.1 of the doc talks about using the HTTP Accept header [field] to indicate supported
PAL Package Types, but IIUC the Accept header field only deals in media types, and the PAL
Package Types are integers.  Absent further details this sounds like it's violating IETF procedures
and thus would get a "type 4" response.