Skip to main content

Concise Software Identifiers
draft-ietf-sacm-coswid-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9393.
Authors Henk Birkholz , Jessica Fitzgerald-McKay , Charles Schmidt , David Waltermire
Last updated 2018-07-02
Replaces draft-birkholz-sacm-coswid
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestones
Jun 2019
WGLC CoSWID
Jul 2020
Submit CoSWID to IESG
Dec 2021
Submit CoSWID to RSE for Publication
Document shepherd (None)
IESG IESG state Became RFC 9393 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sacm-coswid-06
Internet-Draft                   COSWID                        July 2018

Appendix B.  Signed Concise SWID Tags using COSE

   SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include
   cryptographic signatures to protect the integrity of the SWID tag.
   In general, tags are signed by the tag creator (typically, although
   not exclusively, the vendor of the software component that the SWID
   tag identifies).  Cryptographic signatures can make any modification
   of the tag detectable, which is especially important if the integrity
   of the tag is important, such as when the tag is providing reference
   integrity measurements for files.

   The ISO-19770-2:2015 XML schema uses XML DSIG to support
   cryptographic signatures.  CoSWID tags require a different signature
   scheme than this.  COSE (CBOR Object Signing and Encryption) provides
   the required mechanism [RFC8152].  Concise SWID can be wrapped in a
   COSE Single Signer Data Object (cose-sign1) that contains a single
   signature.  The following CDDL defines a more restrictive subset of
   header attributes allowed by COSE tailored to suit the requirements
   of Concise SWID.

<CODE BEGINS>
signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D

label = int / tstr  ; see COSE I-D 1.4.
values = any        ; see COSE I-D 1.4.

unprotected-signed-coswid-header = {
    1 => int,                   ; algorithm identifier
    3 => "application/coswid",  ; request for CoAP IANA registry to become an int
    * label => values,
}

protected-signed-coswid-header = {
    4 => bstr,                  ; key identifier
    * label => values,
}

COSE-Sign1-coswid = [
    protected: bstr .cbor protected-signed-coswid-header,
    unprotected: unprotected-signed-coswid-header,
    payload: bstr .cbor concise-software-identity,
    signature: bstr,
]
<CODE ENDS>

Birkholz, et al.         Expires January 4, 2019               [Page 44]
Internet-Draft                   COSWID                        July 2018

Appendix C.  CoSWID used as Reference Integrity Measurements (CoSWID
             RIM)

   A vendor supplied signed CoSWID tag that includes hash-values for the
   files that compose a software component can be used as a RIM
   (reference integrity measurement).  A RIM is a type of declarative
   guidance that can be used to assert the compliance of an endpoint by
   assessing the installed software.  In the context of remote
   attestation based on an attestation via hardware rooted trust, a
   verifier can appraise the integrity of the conveyed measurements of
   software components using a CoSWID RIM provided by a source, such as
   [I-D.ietf-sacm-rolie-softwaredescriptor].

   RIM Manifests (RIMM):  A group of SWID tags about the same
      (sub-)system, system entity, or (sub-)component (compare
      [RFC4949]).  A RIMM manifest is a distinct document that is
      typically conveyed en-block and constitutes declarative guidance
      in respect to a specific (target) endpoint (compare
      [I-D.ietf-sacm-terminology]).

   If multiple CoSWID compose a RIMM, the following CDDL data definition
   SHOULD be used.

   RIMM = [ + concise-software-identity / signed-coswid ]

Appendix D.  CBOR Web Token for Concise SWID Tags

   A typical requirement regarding specific instantiations of endpoints
   - and, as a result, specific instantiations of software components -
   is a representation of the absolute path of a CoSWID tag document in
   a file system in order to derive absolute paths of files represented
   in the corresponding CoSWID tag.  The absolute path of an evidence
   CoSWID tag can be included as a claim in the header of a CBOR Web
   Token [I-D.ietf-ace-cbor-web-token].  Depending on the source of the
   token, the claim can be in the protected or unprotected header
   portion.

   <CODE BEGINS>
    CDDL TBD
   <CODE ENDS>

Authors' Addresses

Birkholz, et al.         Expires January 4, 2019               [Page 45]
Internet-Draft                   COSWID                        July 2018

   Henk Birkholz
   Fraunhofer SIT
   Rheinstrasse 75
   Darmstadt  64295
   Germany

   Email: henk.birkholz@sit.fraunhofer.de

   Jessica Fitzgerald-McKay
   Department of Defense
   9800 Savage Road
   Ft. Meade, Maryland
   USA

   Email: jmfitz2@nsa.gov

   Charles Schmidt
   The MITRE Corporation
   202 Burlington Road
   Bedford, Maryland  01730
   USA

   Email: cmschmidt@mitre.org

   David Waltermire
   National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, Maryland  20877
   USA

   Email: david.waltermire@nist.gov

Birkholz, et al.         Expires January 4, 2019               [Page 46]