Skip to main content

Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients
draft-turner-sodp-profile-08

Revision differences

Document history

Date Rev. By Action
2021-09-02
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-08-23
08 (System) RFC Editor state changed to AUTH48
2021-07-16
08 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-07-01
08 (System) RFC Editor state changed to REF from EDIT
2021-06-22
08 (System) RFC Editor state changed to EDIT from MISSREF
2021-05-03
08 (System) RFC Editor state changed to MISSREF from EDIT
2021-05-03
08 (System) RFC Editor state changed to EDIT from MISSREF
2021-04-02
08 (System) RFC Editor state changed to MISSREF from EDIT
2021-04-02
08 (System) RFC Editor state changed to EDIT from MISSREF
2021-04-02
08 (System) RFC Editor state changed to MISSREF from EDIT
2021-04-02
08 (System) RFC Editor state changed to EDIT from MISSREF
2021-02-24
08 (System) RFC Editor state changed to MISSREF from EDIT
2021-02-24
08 (System) RFC Editor state changed to EDIT from MISSREF
2021-02-24
08 (System) RFC Editor state changed to MISSREF from EDIT
2021-02-15
08 (System) RFC Editor state changed to EDIT from MISSREF
2020-12-14
08 (System) RFC Editor state changed to MISSREF from EDIT
2020-12-14
08 (System) RFC Editor state changed to EDIT
2020-12-14
08 (System) IANA Action state changed to No IANA Actions from In Progress
2020-12-14
08 (System) IANA Action state changed to In Progress
2020-12-14
08 Adrian Farrel ISE state changed to Sent to the RFC Editor from In ISE Review
2020-12-14
08 Adrian Farrel Sent request for publication to the RFC Editor
2020-09-08
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-09-08
08 Sean Turner New version available: draft-turner-sodp-profile-08.txt
2020-09-08
08 (System) New version accepted (logged-in submitter: Sean Turner)
2020-09-08
08 Sean Turner Uploaded new revision
2020-08-21
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-08-20
07 Sean Turner New version available: draft-turner-sodp-profile-07.txt
2020-08-20
07 (System) New version accepted (logged-in submitter: Sean Turner)
2020-08-20
07 Sean Turner Uploaded new revision
2020-08-12
06 (System) Revised ID Needed tag cleared
2020-08-12
06 Sean Turner New version available: draft-turner-sodp-profile-06.txt
2020-08-12
06 (System) New version accepted (logged-in submitter: Sean Turner)
2020-08-12
06 Sean Turner Uploaded new revision
2020-08-12
05 Adrian Farrel
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 …
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.




2020-08-12
05 Adrian Farrel Tag Revised I-D Needed set. Tag Waiting for Dependency on Other Document cleared.
2020-02-19
05 Sean Turner New version available: draft-turner-sodp-profile-05.txt
2020-02-19
05 (System) New version accepted (logged-in submitter: Sean Turner)
2020-02-19
05 Sean Turner Uploaded new revision
2020-02-17
04 (System) Document has expired
2019-08-16
04 Sean Turner New version available: draft-turner-sodp-profile-04.txt
2019-08-16
04 (System) New version approved
2019-08-16
04 (System) Request for posting confirmation emailed to previous authors: Michael Jenkins , Sean Turner
2019-08-16
04 Sean Turner Uploaded new revision
2019-08-08
03 Adrian Farrel This document is on hold pending a normative reference to draft-authors-tls-profile
2019-08-08
03 Adrian Farrel Tag Waiting for Dependency on Other Document set.
2019-08-07
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-08-07
03 Sean Turner New version available: draft-turner-sodp-profile-03.txt
2019-08-07
03 (System) New version approved
2019-08-07
03 (System) Request for posting confirmation emailed to previous authors: Michael Jenkins , Sean Turner
2019-08-07
03 Sean Turner Uploaded new revision
2019-08-02
02 (System) IANA Review state changed to IANA OK - No Actions Needed
2019-08-02
02 Amanda Baber
(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-turner-sodp-profile-02 and has the following comments:

We understand that this document doesn't require any …
(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-turner-sodp-profile-02 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2019-08-01
02 Adrian Farrel IETF conflict review initiated - see conflict-review-turner-sodp-profile
2019-08-01
02 Adrian Farrel
draft-turner-sodp-profile-02 has been presented for publication as an Informational RFC in the Independent Submission Stream

"The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA's Profile …
draft-turner-sodp-profile-02 has been presented for publication as an Informational RFC in the Independent Submission Stream

"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.




2019-08-01
02 Adrian Farrel ISE state changed to In ISE Review from Response to Review Needed
2019-07-31
02 (System) Revised ID Needed tag cleared
2019-07-31
02 Sean Turner New version available: draft-turner-sodp-profile-02.txt
2019-07-31
02 (System) New version approved
2019-07-31
02 (System) Request for posting confirmation emailed to previous authors: Michael Jenkins , Sean Turner
2019-07-31
02 Sean Turner Uploaded new revision
2019-07-20
01 Adrian Farrel Tag Revised I-D Needed set.
2019-07-20
01 Adrian Farrel ISE state changed to Response to Review Needed from In ISE Review
2019-06-04
01 Adrian Farrel ISE state changed to In ISE Review from Response to Review Needed
2019-06-01
01 (System) Revised ID Needed tag cleared
2019-06-01
01 Sean Turner New version available: draft-turner-sodp-profile-01.txt
2019-06-01
01 (System) New version approved
2019-06-01
01 (System) Request for posting confirmation emailed to previous authors: Michael Jenkins , Sean Turner
2019-06-01
01 Sean Turner Uploaded new revision
2019-05-07
00 Adrian Farrel Tag Revised I-D Needed set. Tag Awaiting Reviews cleared.
2019-05-07
00 Adrian Farrel ISE state changed to Response to Review Needed from In ISE Review
2019-04-30
00 Adrian Farrel Tag Awaiting Reviews set.
2019-04-30
00 Adrian Farrel ISE state changed to In ISE Review from Finding Reviewers
2019-04-30
00 Adrian Farrel ISE state changed to Finding Reviewers from Submission Received
2019-04-22
00 Adrian Farrel Notification list changed to Adrian Farrel <rfc-ise@rfc-editor.org>
2019-04-22
00 Adrian Farrel Document shepherd changed to Adrian Farrel
2019-04-22
00 Adrian Farrel ISE state changed to Submission Received
2019-04-22
00 Adrian Farrel Intended Status changed to Informational from None
2019-04-22
00 Adrian Farrel Stream changed to ISE from None
2019-03-25
00 Sean Turner New version available: draft-turner-sodp-profile-00.txt
2019-03-25
00 (System) New version approved
2019-03-25
00 Sean Turner Request for posting confirmation emailed  to submitter and authors: Michael Jenkins , Sean Turner
2019-03-25
00 Sean Turner Uploaded new revision