Skip to main content

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

Document history

Date Rev. By Action
2020-08-31
00 Amy Vezza
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,
    …
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



2020-08-31
00 Amy Vezza IESG has approved the conflict review response
2020-08-31
00 Amy Vezza Closed "Approve" ballot
2020-08-31
00 Amy Vezza Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent
2020-08-27
00 Benjamin Kaduk
[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

  …
[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?
2020-08-27
00 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from No Record
2020-08-27
00 Cindy Morgan Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation
2020-08-27
00 Roman Danyliw
[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 …
[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.
2020-08-27
00 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-08-27
00 Roman Danyliw
[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 …
[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.
2020-08-27
00 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-08-27
00 Benjamin Kaduk
[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 …
[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.
2020-08-27
00 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2020-08-26
00 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-08-26
00 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-08-26
00 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-08-26
00 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-08-25
00 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-08-24
00 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-08-24
00 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-08-21
00 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-08-21
00 Roman Danyliw Created "Approve" ballot
2020-08-21
00 Roman Danyliw Conflict Review State changed to IESG Evaluation from AD Review
2020-08-21
00 Amy Vezza Placed on agenda for telechat - 2020-08-27
2020-08-21
00 Roman Danyliw New version available: conflict-review-turner-sodp-profile-00.txt
2020-08-13
00 Amy Vezza Conflict Review State changed to AD Review from Withdrawn
2019-08-08
00 Cindy Morgan Conflict Review State changed to Withdrawn from AD Review
2019-08-07
00 Cindy Morgan Removed from agenda for telechat
2019-08-02
00 Alissa Cooper Conflict Review State changed to AD Review from Needs Shepherd
2019-08-02
00 Alissa Cooper Shepherding AD changed to Roman Danyliw
2019-08-01
00 Amy Vezza Placed on agenda for telechat - 2019-08-08
2019-08-01
00 Adrian Farrel IETF conflict review requested