1.6 dev cbom

[jkowalleck]

specific goals:

• fixes Add cryptographic assets as new component type #171
• fixes CBOM: make certificationLevel extensible #291

task list for spec enhacement

• schema: JSON
• schema: XML
• schema: protobuff
• examples/test cases

[jkowalleck]

created this PR to make an early review easier.

[jkowalleck]

did a quick review, noted some thoughts

[bhess]

• dependencyType:

  • Should we change protected-by to protects so that the dependency relationship goes the same direction as uses and implements? This doesn't feel natural to me? But I'm not sure if there's a technical reason why it should be this way. Seeking input.

"dependencies": [
    {
      "ref": "acme-application",
      "type": "uses",
      "dependsOn": ["crypto-library"]
    },
    {
      "ref": "crypto-library",
      "type": "implements",
      "dependsOn": ["aes128gcm"]
    },
    {
      "ref": "some-data",
      "type": "protected-by",
      "dependsOn": [ "crypto-library" ]
    }
  ]

It might be more common from the perspective of data to know with which crypto asset it is "protected-by" than knowing for a crypto asset what data it "protects".

certificationLevel:

• Should this be an array? Currently its a single field which would prevent multiple certifications from being specified.

I agree, an array would be useful.

signatureAlgorithm, subjectPublicKey

• Currently these two fields refer to other components by their bom-ref. Another field algorithmRef also does this. The spec should be consistent. Should we add Ref to the signatureAlgorithm and subjectPublicKey fields? or should we drop it from the algorithmRef field?

Tagging @n1ckl0sk0rtge for your thoughts. signatureAlgorithm and SubjectPublicKey are fields for certificates and algorithmRef is a field in relatedCryptoMaterial. I think it's useful to be able to express these references. Ok with me to make it more consistent though.

[jkowalleck]

@stevespringett @bhess is this ready for review?
how about the conflicts?

[stevespringett]

@jkowalleck I need to make a few minor changes this weekend that were a result of this weeks FWG meeting and will resolve the conflicts as well.

[stevespringett]

I just now found and corrected some missing fields in the XSD and Protobuf and have done a review. I do not see any blocking issues that would prevent acceptance. Additionally, the single issue identified by an IBM TC54 member has been corrected.