This is an open ticket to track improvements in test coverage.

We need some sort of scripts/presubmit.sh which mirrors the CI tests, i.e., linters and code coverage that can be used before submitting the PR to minimise dev roundtrips.

Add support for metadata fields as per section 4 of TCG RIM in CoSWID.
• BindingSpecVersion
• PlatformManufacturerId
• PlatformManufacturerStr
• PlatformModel
• FirmwareManufacturer
• FirmwareManufacturerId

Also, please add other related extensions.

Looking at https://tools.ietf.org/rfcdiff?url2=draft-ietf-sacm-coswid-17.txt it seems like we need to move around a number of smallish things:

• payload or evidence cardinality:

payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )

• ownership type (was unsigned):

$ownership /= int / text

• use type (was unsigned):

$use /= int / text	

• file-entry size type:

? size => uint,

• directory-entry path-elements is optional:

? path-elements => { path-elements-group },

• evidence-entry date type:

? date => integer-time,

• any-uri type

any-uri = uri

• 7. Signed CoSWID Tags (currently not implemented)
• 8. Tagged CoSWID Tags

any-uri is an alias for uri.

Therefore, entity-entry's reg-id and link-entry's href need to be #6.32(tstr) rather than tstr

https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-18.html#section-2.3:

   *  tag-id (index 0): [...] If represented as a 16 byte binary
      string, the identifier MUST be a valid universally unique
      identifier as defined by [RFC4122]

However, we currently do no validation on the supplied byte array, except for the 16 bytes constraint.

Also, given that the type of the byte array is well defined and it has a known string representation, we should also allow it in XML and JSON.

While implementing CoRIM, a couple of limitations in the current hash-entry implementation became visible:

1. the algorithm identifiers are not visible outside the swid package, which forces consumers to replicate the codepoints
2. the current implementation does not check compatibility of the inputs (algID and hashValue) on Set, which means you can end up with meaningless combos.

Add templates for issues (code bugs, issues with documentation, feature requests) and pull requests.

What version of the package are you using?

Current

Does this issue reproduce with the latest release?

Yes

What OS and CPU architecture are you using (go env)?

GOARCH="amd64"
GOOS="darwin"

GOHOSTARCH="amd64"
GOHOSTOS="darwin"

What did you do?

Tried parsing XML SWID tags generated using NIST's swid-tools and StrongSwan's swidGenerator using the FromXML method on swid.SoftwareIdentity.

What did you expect to see?

I expected it to successfully parse.

What did you see instead?

An error indicating bad format: expecting :

An issue is that the codify invocation at https://github.com/veraison/swid/blob/main/hashentry.go#L216 is expecting : but is being passed . If the SWID tag is modified to include SHA256: in the value, for example, parsing is successful.

Additionally, there appears to be intolerance of multiple hash attributes. Two samples (one with one hash attribute and one with two) are below. When the sample with two hash attrs was modified as described above to parse successfully then serialized as JSON, only the second attribute was emitted.

We currently have a tool: https://github.com/veraison/corim/tree/main/cocli
to construct CoRIM and CoMID.
The CoRIM tool, takes a CBOR dump of CoSWID when including a CoSWID inside the CoRIM.

It would help, if we can have a similar tool inside CoSWID repository for a rapid construction of CoSWID/SWID from given templates!

Currently it is left as an exercise for the user to make sure the assembled (Co)SWID is syntactically correct, e.g., that all non-optional fields have been correctly filled in and that any co-constraint is satisfied.

Ideally, the library should provide this facility via a public Valid() error function that is implemented by each component and can be recursively called by the top-level SoftwareIdentity.

tag-id fails decoding because it is just a naked interface. We need to wrap it into a custom type and provide the marshal/unmarshal methods for each target format.

Mval struct does not contain the ‘name’ field in it.
TCG document ([https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-r38_5May22.pdf] "section 5.5.3.1.12 measurement-values-map" lists the fields to be kept in measurement-values-map. It contains "name" field. Same is not reflected in [https://github.com/veraison/corim/blob/9a7830b4a3c319a5e0d5f14c986c828f8417a158/comid/measurement.go#L166]

Due to this, cocli does not support/add the name field while generating comid.cbor even if we manually add a name field in comid.json.

The Rel object does not have getter/setter methods and is therefore unusable from outside the swid package.

it'd be nice to reuse version scheme from other packages (e.g., https://github.com/veraison/corim), but this is not possible right now because the type is opaque and there is no setter method.

“cocli corim sign” tool does not work with a key curve P-384. It throws below error:

Error: error loading signing key from ec-p384.jwk: unknown elliptic curve {0xc00007e400}

The ec-p384.jwk file is as below:
{
"kty": "EC",
"d": "XiZ_ZEDMw3Hr9BjNc_4qbNxMG6VpkFHTN3KcdT1UlOc51pFwS1t6Yg_aFYJTGMBf",
"use": "sig",
"crv": "P-384",
"x": "Ay-c_vlONI_FNQn4PNHXwEswuoxOTqOEHNIQbSKv5OnC_KBLwAbg5uBQRHCRmFnu",
"y": "mJpRrG-ex0R08heh1qm-osCH7SSTKC1Bjx1SrFpUQZCiYQXdPLIokC0DGRAMYq41",
"alg": "ES384"
}

We have taken the CoRIM route in the meantime, all PSA extensions are basically dead code.