Re: [Suit] Information model updates

[Dick Brooks <[e-mail]>]

Will do, Russ.

 

Just an FYI:

 

Here is a snippet from a discussion within NAESB today regarding supplier identification, signing key verification and the issuance of code signing keys. NAESB is in the process of updating it’s PKI standard as a first step to address this matter:

 

There is some support to use a dns:identifier within certain SBOM fields, here’s an SBOM example:

 

SPDXVersion: SPDX-2.2

DataLicense: CC0-1.0

SPDXID: SPDXRef-DOCUMENT

DocumentName: SAG-PM generated SBOM

DocumentNamespace: dns:softwareassuranceguardian.com

Creator: Organization: dns:reliableenergyanalytics.com

 

Using this example I could envision the DNS Zone file for reliableenergyanalytics.com

 

Having a DSA record identifying dns:ssl.com as an authorized signer for reliableenergyanalytics.com. This would enable a CA. i.e. GlobalSign, that receives a code signing CSR  to check reliableenergyanalytics.com DNS Zone file for a DSA record listing ssl.com as a authorized signer. 

 

This won’t solve the entire software supply chain issue with regard to identity and authorized signer verification, but it’s a good first step, that is missing today.

 

I’ll let you and the SUIT WG know if the concern I raised is already covered in draft-ietf-suit-manifest-13.

 

Thanks for looking into this.

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Russ Housley <[e-mail]> 
Sent: Tuesday, May 25, 2021 5:22 PM
To: Dick Brooks <[e-mail]>
Cc: suit <[e-mail]>; Brendan Moran <[e-mail]>
Subject: Re: [Suit] Information model updates

 

Dick:

 

Please take a look at the current WG document (draft-ietf-suit-manifest-13).  I think that the discussion of dependencies and their processing is what you are asking about.

 

Russ

 





On May 24, 2021, at 10:19 AM, Dick Brooks <[e-mail] <mailto:[e-mail]> > wrote:

 

Thanks, Russ. Sorry about that – here is the article contents – thanks for your insights and recommendation. Very interested in knowing your thoughts, especially regarding the DNS DSA concept.

 

We cannot secure the software supply chain without SBOM

 

A Software Bill of Materials (SBOM) <https://ntia.gov/sbom>  has received considerable attention since the Cybersecurity Executive order was released on May 12, 2021 <https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/>  calling on government agencies to require SBOM’s from software vendors, “(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website” 

The Executive Order goes on to describe an SBOM, with an emphasis on it’s component inventory capabilities, “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software”, “It is analogous to a list of ingredients on food packaging.”

All of these claims are indeed accurate, however there is another essential and critically important element that SBOM’s provide, which is essential to secure the software supply chain; The identity of the software source supplier that produced and licensed the software, which can be verified using digital signing keys issued by trustworthy Certificate Authorities. 

Current practices used in the software supply chain do not require identification of the actual software supplier and licensor of a software package. Some practices require that software packages be digitally signed, however there is no verification or validation that the signer of a software package and the supplier/licensor are related, or that the supplier/licensor has authorized a given party to sign a software object on their behalf. This creates a false sense of security when parties rely on tools such as Microsoft’s signtool to validate a digital signature. Signtool does not validate that a digital signature is indeed authorized to sign a software product on behalf of the original source supplier/licensor – it has no way of verifying that a given signing key is authorized to sign a software package. Signtool will report a valid signature if the cryptographic verifications and trust chain reports produce successful results, which do not verify the authorization of a signing party and supplier arrangement. This issue is similar to a past scenario where Certificate Authorities were issuing SSL certificates to domains without authorization to do so, which resulted in the implementation of DNS CAA (IETF RFC 6844 <https://datatracker.ietf.org/doc/html/rfc6844> ) records to identify authorized parties to issue SSL certificates. A similar authorization scheme may be appropriate to authorize the issuance of digital certificates and signing keys to parties that have been authorized by a software supplier/licensor to sign software objects on their behalf.

The ability to determine trustworthiness is the key to securing the software supply chain. SBOM is the foundation for establishing this trust by specifying the identification of the actual source supplier/licensor of a software product. This supplier information can then be used to validate a digital signature applied to a software object by verifying the relationship of the software supplier and software signer using a trusted method to verify this relationship. A solution similar to DNS CAA, ref: “DNS Certification Authority Authorization (CAA) Resource Record”, IETF RFC 6844 <https://datatracker.ietf.org/doc/html/rfc6844>  may be worth exploring to address this need.
 
There is no doubt that securing the software supply chain requires a software consumer to verify the identity of a software source supplier and licensor of a software object. SBOM is a critical requirement in this process due to its standard method for identifying a software supplier/licensor of a software object. Having this SBOM supplier identifier will enable a software consumer to verify this party using digital signatures based on digital certificates issued by trusted Certificate Authorities.  What is missing today is a means to verify the authorization of a signing party by the software source supplier/licensor using trusted mechanisms, similar to RFC 6844. Perhaps, one day, we may see a DNS Digital Signature Authorization (DSA) record to meet this need. 
 

Thanks,

 

Dick Brooks

<image001.jpg>

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Russ Housley <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, May 24, 2021 10:14 AM
To: [e-mail] <mailto:[e-mail]> 
Cc: Brendan Moran <[e-mail] <mailto:[e-mail]> >; suit <[e-mail] <mailto:[e-mail]> >
Subject: Re: [Suit] Information model updates

 

Dick:

 

To read the article that you reference, I must join "The Energy Collective Group".  If you want us to consider your thoughts, you need to make them freely and openly available. Posting them here also has the desirable property that they get included in the mail archive of the WG discussion.

 

Russ






On May 24, 2021, at 10:01 AM, Dick Brooks <[e-mail] <mailto:[e-mail]> > wrote:

 

Russ, et al,

 

               I’ve raised an issue with regard to software supplier identification and verification as part of a software supply chain verification. I haven’t been paying much attention to the SUIT and MUD work, so I would be curious to know if this issue also effects your work in this area. 

 

https://energycentral.com/c/ec/we-cannot-secure-software-supply-chain-without-sbom

 

Thanks,

 

Dick Brooks

<image001.jpg>

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Suit <[e-mail] <mailto:[e-mail]> > On Behalf Of Russ Housley
Sent: Monday, May 24, 2021 9:55 AM
To: Brendan Moran <[e-mail] <mailto:[e-mail]> >
Cc: suit <[e-mail] <mailto:[e-mail]> >
Subject: Re: [Suit] Information model updates

 

The IESG is waiting for a revised Internet-Draft to be posted.

 

Russ







On May 13, 2021, at 6:06 AM, Brendan Moran <[e-mail] <mailto:[e-mail]> > wrote:

 

I’ve made a number of pull requests to the information model. These should address the issues raised by IESG review. 

 

See here for more information: https://github.com/suit-wg/information-model/pulls

 

Brendan

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 

_______________________________________________
Suit mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/suit

 

_______________________________________________
Suit mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/suit> https://www.ietf.org/mailman/listinfo/suit

 

_______________________________________________
Suit mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/suit> https://www.ietf.org/mailman/listinfo/suit