Skip to main content

Shepherd writeup
draft-turner-sodp-profile

draft-turner-sodp-profile-02 has been presented for publication as an
Informational RFC in the Independent Submission Stream

** NOTE ** This document was previously presented to the IESG for 5742 review,
but had a normative dependency on draft-cooley-cnsa-dtls-tls-profile which was
not ready, so the review request was withdrawn.
draft-cooley-cnsa-dtls-tls-profile has now entered IESG review, so we are ready
to move this document forward again. At the time of the first review request,
Roman Danyliw made some initial comments on the draft and they were addressed
by the authors in a new revision.

"The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA's Profile
for Delivery of Certificates, CRLs, and Symmetric Keys to Clients" is one of a
sequence of documents describing security profiles as defined by the United
States National Security Agency.

The purpose of the profiles is to state which options and configurations of
IETF security protocols are required for deployment in US National Security
Systems. This enables implementers to participate in such systems and also for
others who need to similarly profile secrity protocols to have a base reference.

The document is clear in the Abstract and Introduction about its purpose, and
it should be clear that this is not an IETF consensus document.

No IANA action is requested.

Along the way, the document was reviewed by Russ Housley and me. The reviews
are attached below for your information.

== Russ Housley ==

Summary:  Accept and publish after the comments are addressed

Major Concerns:

Section 3.5: The text says:

   Clients always use an explicit TA database ([RFC7030], Section
   3.6.1).  At a minimum, clients support two TAs; one for the PKI and
   one for symmetric keys.

However, the Introduction says that clients do not have to support
everything in this profile. Is this an exception?  If not, clients that
use PKI support a PKI TA, and clients that use symmetric keys support
a symmetric key TA.

Section 11: It seems odd to list TAMP and Firmware here since
Section 3.6.10 says that they are not supported by this profile.

Minor Concerns:

The Abstract is very long.  I understand why all of the things said
there need to be in the document, but can some of it be moved to the
Introduction?

Section 1.1 says:

   The requirements from profiled RFCs apply throughout this profile and
   are generally not repeated here.

Can this be worded without "profile" being used twice?  It also seems to
really apply only to the last bullet in the list that comes before.

Section 1.3: It would probably help to include either CRLs in
Figure 1.

Section 3.6.3: The use of the word "except" is not clear.  Are the two
things listed not specified in Section 5.1 of ID.cnsa-cmc-profile]?  Or,
are the two things listed not part of this profile?  Please reword.

Section 4.5: The use of the word "except" is not clear.  Are the two
things listed not specified in Section 5.1 of ID.cnsa-cmc-profile]?  Or,
are the two things listed not part of this profile?  Please reword.

Other Editorial Comments:

Section 1: s/PKCS 10 requests/PKCS#10 requests/
           s/PKCS 7 responses/PKCS#7 responses/

Section 1.1: The text says: "CMS-related (Cryptographic Message Syntax)",
which is correct, but CMS has already been expanded in Section 1, so it
does not need to be expanded here too.

Section 1.3:  The text says: '"secured" minimally', but I think you are
trying to say that the objects or packages are always digitally signed,
and they might also be encrypted.

Section 3.3: The text says:

   Servers only enroll clients that they have a previously established
   relationship with.

I suggest:

   Servers enroll only clients that already have an established
   relationship.

Section 3.6.6: s/PKCS12 [RFC7292]/PKCS#12 [RFC7292]/

Section 7.1: s/CMS Content Constraints/CMS Content Constraints (CCC)/
(This is important because CCC is used elsewhere, so a search for "CCC"
needs to find this paragraph, which says that the CCC will be marked as
critical.  Thus, SOA certificates cannot be processes if this extension
is not understood.)

Section 8: s/CMS Content Constraints/CMS Content Constraints (CCC)/

== Adrian Farrel ==

Abstract is, perhaps a tad long. Maybe the final paragraph isn't needed.

---

Section 1.1

   The requirements from RFCs apply throughout this profile and are
   generally not repeated here.  This document is purposely written
   without RFC 2119-language.

That probably needs a reference to RFC 2119 or simply remove the final
sentence.

---

Copy-edit might fix this anyway, but the correct English way of handling
optional plurals is to use the plural. Thus...

   For clients that support the CMC interface and not the EST interface,
   the environment includes only the PKI TA(s).

should read...

   For clients that support the CMC interface and not the EST interface,
   the environment includes only the PKI TAs.

---

3.2.  Transport Layer Security

   TLS implementations are configured as specified in
   [ID.cnsa-tls-profile]; the notable exception is that RSA-based
   algorithms are not supported.

Do you mean "not used" or possibly "do not need to be supported" or even
"must not be used"? If an implementation chooses to support RSA-based
algorithms that surely does not invalidate it so long as those
algorithms are not used.

---

3.6.4.  /simplereenroll

   Nothing additional for requests beyond what is specified in Sections
   3.4 and 3.6.3 of this document.

This is not a sentence.

---

3.6.7.  /csrattrs

   Clients use this service to retrieve partially filled PKIRequests;
   PKIRequests with no public key or proof-of-possession signature,

I think you mean to use a colon not a semicolon.

---

3.6.9.  /symmetrickeys

       /serverkeygen/return is not supported at this time.

Again, "not supported" may be "not used" or "no support is needed".
But I also don't like "at this time" -- what other time would this
document describe?

---

3.6.10.  /eecerts, /firmware, /tamp

   /eecerts, /firmware, /tamp are not supported at this time.

Ditto

---

4.2

"That looks very familiar," I thought.
Is this in any way different from 3.3? Why say it twice?

Maybe 3.3 needs "...at the EST interface" and 4.2 needs "...at the CMC
interface".

---

Section 5, 6, 7, 8, and 9

   RSA-based algorithms are not supported.

As before.

Note that you say it twice in Section 7 :-)

---

7.1.  Source of Authority Certificate Profile

   This section specifies the format for SOAs certificates, i.e.,

s/SOAs/SOA/ ?

---

7.2

   The following extensions are also included when needed:

Is the reader supposed to know how to determine the "need"?

---

Section 8

   RPs should support the following extensions: CRL Distribution Points,
   Authority Information Access, Subject Directory Attribute,  Authority
   Clearance Constraints, and CMS Content Constraints extensions.

   Within the Subject Directory Attribute extension, RPs should support
   the Clearance Sponsor, Clearance, and Device Owner attributes.

This "should support" suggests that not supporting is OK. But do you
need  to say anything about what happens when any of these extensions is
not supported?

---

9.  CRL Profile

   This section documents requirements in addition to those listed in
   [RFC8603], which in turn specifies requirements in addition to those
   in [RFC5280], for CRLs.

Would be nicer as

   This section documents requirements for CRLs in addition to those
   listed in [RFC8603], which in turn specifies requirements in addition
   to those in [RFC5280].

---

11.  Security Considerations

   This entire document is about security.  This document profiles the
   use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as
   well as X.509 certificates and extensions.  These have been referred
   to throughout this document and those specifications should be
   consulted for security considerations related to implemented protocol
   and services.

While you do have references to RFC 3739 and  RFC 5280, this is the
first mention of X.509 and I wonder if you should fix that.

Back