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 |