Draft: draft-ietf-sacm-coswid

Commentary: Addressed the following comments : [ Per IETF 110 ] Add text on the order of native CDDL approach for handling version is used . If a future version of SWID is published which alters the semantics of exists fields , a future version of CoSWID  ( MUST ? ) use a different tag to represent it . [ daw : A new paragraph was to section 2 detailing how index values are used to support revisions and extensions . ] [ Per IETF 110 ] see -16 . Use ISO SWID reference for the IANA registry and if desired , used [ SEMVER ] as an informal reference in the text [ daw : This has been done in section 4.1 . ] [ daw : The FIXME markers have been replaced with actual text . ] [ daw : Section 7 now details the construction of a signed CoSWID . A SHOULD sign requirement was also to section 7 . ] [ Per IETF 110 ] We discussed adding language on the order of " This document specifies a data format and an associated integrity mechanism agnostic of a deployment . Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances . " [ -15 ] Section 6 . Per " When an authoritative tag is signed , the software [ daw : Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer . We are working out a means to do this . ] 2 [ daw : Not sure which tags this applies to ? Signing ? All of section 2 ? ] [ daw : done . ] [ daw : This confusing text has been removed . ] [ daw : done . ] [ daw : We a note about this . ] [ daw : Done . ] [ daw : Added signature validation as a way . ] Regards , Roman
Paragraph (version B):
Through use of CDDL-based integer labels, CoSWID allows for future
expansion in subsequent revisions of this specification and through
extensions (see model-extension).  New constructs can be associated
with a new integer index.  A deprecated construct can be replaced by
a new construct with a new integer index.  An implementation can use
these integer indexes to identify the construct to parse.  The CoSWID
Items registry, defined in iana-coswid-items, is used to ensure that
new constructs are assigned a unique index value on a first-come,
first-served basis.  This approach avoids the need to have an
explicit CoSWID version.
Paragraph (version A):
Signing CoSWID tags follows the procedues defined in CBOR Object
Signing and Encryption RFC8152.  A CoSWID tg MUST be wrapped in a
COSE Single Signer Data Object (COSE_Sign1) that contains a single
signature and MUST be signed by the tag creator.  The following CDDL
specification defines a restrictive subset of COSE header parameters
that MUST be used in the protected header.
Paragraph (version B):
Signing CoSWID tags follows the procedures defined in CBOR Object
Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a
COSE Single Signer Data Object (COSE_Sign1) that contains a single
signature and MUST be signed by the tag creator.  The following CDDL
specification defines a restrictive subset of COSE header parameters
that MUST be used in the protected header.
Paragraph (version B):
A CoSWID SHOULD be signed, using the above mechanism, to protect the
integrity of the CoSWID tag.  See the security considerations (in
sec-sec) for more information on why a signed CoSWID is valuable in
most cases.
Paragraph (version A):
A tag is considered "authoritative" if the CoSWID tag was created by
the software provider.  An authoritative CoSWID tag contains
information about a software component provided by the maintainer of
the software component, who is expected to be an expert in their own
software.  Thus, authoritative CoSWID tags can be trusted to
represent authoritative information about the software component.
Paragraph (version A):
A signed CoSWID tag (see coswid-cose) whose signature has been
validated can be relied upon to be unchanged since it was signed.  By
contrast, the data contained in unsigned tags cannot be trusted to be
unmodified.
Paragraph (version A):
When an authoritative tag is signed, the software provider can be
authenticated as the originator of the signature.  A trustworthy
association between the signature and the originator of the signature
can be established via trust anchors.  A certification path between a
trust anchor and a certificate including a pub-key enabling the
validation of a tag signature can realize the assessment of
trustworthiness of an authoritative tag.  Having a signed
authoritative CoSWID tag can be useful when the information in the
tag needs to be trusted, such as when the tag is being used to convey
reference integrity measurements for software components.
Paragraph (version B):
A tag is considered "authoritative" if the CoSWID tag was created by
the software provider.  An authoritative CoSWID tag contains
information about a software component provided by the supplier of
the software component, who is expected to be an expert in their own
software.  Thus, authoritative CoSWID tags can represent
authoritative information about the software component.  The degree
to which this information can be trusted depends on the tag's chain
of custody and the ability to verify a signature provided by the
supplier if present in the CoSWID tag.  The provisioning and
validation of CoSWID tags are handled by local policy and is outside
the scope of this document.
Paragraph (version B):
A signed CoSWID tag (see coswid-cose) whose signature has been
validated can be relied upon to be unchanged since it was signed.  By
contrast, the data contained in unsigned tags can be altered by any
user or process with write-access to the tag.  To support signature
validation, there is the need associate the right key with the
software provider or party originating the signature.  This operation
is application specific and needs to be addressed by the application
or a user of the application; a specific approach for which is out-
of-scope for this document.
Paragraph (version B):
When an authoritative tag is signed, the originator of the signature
can be verified.  A trustworthy association between the signature and
the originator of the signature can be established via trust anchors.
A certification path between a trust anchor and a certificate
including a public key enabling the validation of a tag signature can
realize the assessment of trustworthiness of an authoritative tag.
Verifying that the software provider is the signer is a different
matter.  This requires an association between the signature and the
tag's entity item associated corresponding to the software provider.
No mechanism is defined in this draft to make this association;
therefore, this association will need to be handled by local policy.
Paragraph (version A):
Finally, both the ISO-19770-2:2015 XML schema SWID definition and the
CoSWID CDDL specification allow for the construction of "infinite"
tags with link item loops or tags that contain malicious content with
the intent of creating non-deterministic states during validation or
processing of those tags.  While software providers are unlikely to
do this, CoSWID tags can be created by any party and the CoSWID tags
collected from an endpoint could contain a mixture of vendor and non-
vendor created tags.  For this reason, a CoSWID tag might contain
potentially malicious content.  Input sanitization and loop detection
are two ways that implementations can address this concern.
Paragraph (version B):
Finally, both the ISO-19770-2:2015 XML schema SWID definition and the
CoSWID CDDL specification allow for the construction of "infinite"
tags with link item loops or tags that contain malicious content with
the intent of creating non-deterministic states during validation or
processing of those tags.  While software providers are unlikely to
do this, CoSWID tags can be created by any party and the CoSWID tags
collected from an endpoint could contain a mixture of vendor and non-
vendor created tags.  For this reason, a CoSWID tag might contain
potentially malicious content.  Input sanitization, loop detection,
and signature verification are ways that implementations can address
this concern.