Use consistent control identifiers

[matoszz]

User Story

As an OSCAL consumer / developer, it would make my life significantly easier if a consistent control identifier / format would be used which matches other NIST tooling / identifier mappings.

Goals

Goal would be that the OSCAL id field used for controls (within control groups (inside of catalogs)) uses a consistently formatted ID. Today, when trying to consume OSCAL / oscal-content, it's incredibly confusing that the id field does not match the format used by other tools such as CPRT; CPRT introduced "leading 0's" (https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) into the control identifier, so when you output a mapping you get:

        {
          "element_type": "control",
          "element_identifier": "AC-01",
          "title": "POLICY AND PROCEDURES",
          "text": "",
          "doc_identifier": "SP_800_53_5_1_1"
        },
        {
          "element_type": "control",
          "element_identifier": "AC-02",
          "title": "ACCOUNT MANAGEMENT",
          "text": "",
          "doc_identifier": "SP_800_53_5_1_1"
        },
        {
          "element_type": "control_enhancement",
          "element_identifier": "AC-02(01)",
          "title": "AUTOMATED SYSTEM ACCOUNT MANAGEMENT",
          "text": "",
          "doc_identifier": "SP_800_53_5_1_1"
        },

but the OSCAL publications identifier is in a format that's ac-1 (non-padded, lower case. The sub-identifiers are also separated by a period instead of with parenthesis (ac-2.1 vs. AC-02(01)). Within the props of a control there exists multiple permutations of identifiers:

                "props": [
                  {
                    "name": "label",
                    "value": "AC-02(02)",
                    "class": "zero-padded"
                  },
                  {
                    "name": "label",
                    "value": "AC-2(2)"
                  },
                  {
                    "name": "label",
                    "value": "AC-02(02)",
                    "class": "sp800-53a"
                  },
                  {
                    "name": "sort-id",
                    "value": "ac-02.02"
                  },
                  {
                    "name": "implementation-level",
                    "ns": "http://csrc.nist.gov/ns/rmf",
                    "value": "system"
                  }
                ],

without a lot indication on whether or not the id field should be used or the zero-padded value or the non-padded variation. I'm currently writing a lot of unnecessary code to include OSCAL formats as a part of our compliance standards because of the variation in these identifiers and the inconsistent use of identifiers in other NIST projects / publications.

additional reference: usnistgov/oscal-content#281

Dependencies

No response

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[iMichaela]

@matoszz - We value your opinion and understand your frustration. Unfortunately, OSCAL representation of 800-53 rev 5.1.1 had to provide traceability for the controls in the 800-53 rev4 and to ensure accuracy with the initial and current (CPRT) representation of the 800-53 catalog. NIST RMF team introduced zero-leading control numbers in SP800-53 rev5.1.1 after OSCAL team demonstrated the importance of sortable mechanisms for the controls using props . A change in the IDs in rev 5.1.1 would have caused a backwards incompatibility issue impacting OSCAL users when transitioning from rev4 controls to rev5 controls and the latest 5.1.1 controls.
We regret we cannot accommodate your request. We hope that we will be able to do some reformatting for SP 800-53 rev6, but traceability of the controls between versions is very important for long term users of 800-53 and substantially decreases their efforts during transitions between versions of 800-53.