Subject: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

From: "Dick Brooks" <[email-masked]>
Date: Sun, 6 Jun 2021 10:22:09 -0400

This is NOT specific to SUIT, but it is germane to earlier discussions.

Just an FYI, I sent this to the NIST code-signing and supply chain email distribution lists today:

From: Dick Brooks <[email-masked]> 
Sent: Sunday, June 6, 2021 9:43 AM
To: 'swsupplychain-eo' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Surprising push-back on digital signature verification requirement

I've received a surprising amount of push-back from people claiming that this is not a real concern, stating that a digital signature on software is "good enough" to establish trust and I'm just spreading FUD. I disagree, this is like saying that an Executive Order signed by anyone other than President Biden "is good enough" and are just as enforceable as an EO signed by the President. My signature on an Executive Order does not make it valid. 

The same is true for a software package that is singed by anyone except the authorized signing party - either the source supplier or a verifiable "proxy" authorized by the source supplier, as I reported here. Any other digital signature on a software package should be rejected as illegitimate. A reliable verification mechanism is needed so that customers can verify the trust relationship between a software supplier and digital signer on a software package during digital signature validation. I agree with the conclusion and recommendations of the highly credible experts in the CAB Forum; sw customers need a mechanism to verify the trust relationship between a software supplier and an authorized signer on a software package during the digital signature verification process and the quest for a solution is “encouraged”. 

A failure to verify this trust relationship should result in the software being considered untrustworthy and should never be installed.

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Friday, June 4, 2021 7:06 AM
To: 'Brendan Moran' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Information model updates

Brendan,

I agree: " SUIT Trust Anchors may not even be available via conventional PKI, so verification by intermediaries MUST be done using explicit Trust Anchors with explicit permissions."

FYI: The CAB Forum discussed the verification of a digital signer - Software supplier relationship verification as an issue that exists today (see email I received from Sebastian copied here from CAB Forum discussion on the matter":
Conclusion: " there’s acknowledgement that this is a real problem and innovation for finding a solution to the problem would be encouraged. "

A solution may be on the horizon from CA's offering code signing services: 
" There’s a special case for CodeSigning Services operated by CAs, something that will receive more attention during the coming months. In that case, the CA may actually have visibility of what Code is being signed (or at least the hash) and could therefore operate such databases. Whether that would really see a cross-industry record/database (like CAA) emerge depends on whether a good technical concept can be developed (like RFCs 6844 and 8659 for CAA)."

Full body of email follows:
----------EMAIL
Hey Dick,

We discussed the matter first between members of the working group, so I can already share the consensus with you:

While this is certainly interesting for certificate consumers (like Microsoft) a CAA model doesn’t quite work here. CAA allows certificate issuers (like GlobalSign) to check DNS records before issuing to a certain domain, the CA basically verifies its authorization to issue a certificate to a particular domain. Now for CodeSigning, certificates are issued to companies. Something akin to CAA has actually been discussed already but it’d would cover organizations granting authority to certain CAs to issue a CodeSigning certificate in their name to mitigate fraudulent issuance, it doesn’t solve the problem of unauthorized signing.

For signing code itself, the CA has no visibility of what Code is being signed. So a check whether a particular certificate is authorized to sign certain code would have to be performed by the signing tool. There was some consensus that there’s room for innovation with signing tools – some of those already support multiple signatures on code (for author, distributor and platform for example) so a database could be set up that checks whether a particular combination of signatures is permitted (e.g. the author allows distribution only by select other companies). For actually checking the authorization of a signer to sign certain code, there’s the complexity of logging this. Creating a database with application hashes and authorized signers would be one approach but leaves openings when code is altered in some way and also has an obvious problem with scalability.

There’s a special case for CodeSigning Services operated by CAs, something that will receive more attention during the coming months. In that case, the CA may actually have visibility of what Code is being signed (or at least the hash) and could therefore operate such databases. Whether that would really see a cross-industry record/database (like CAA) emerge depends on whether a good technical concept can be developed (like RFCs 6844 and 8659 for CAA).

As for the status quo – there’s not really something the CA industry can do right now but there’s acknowledgement that this is a real problem and innovation for finding a solution to the problem would be encouraged.

Because we deemed the question indeed very relevant for the working group I will repost your question to the public list and we will answer it on the public list as well, so that other subscribers can also see it.

Best,
Seb

Sebastian Schulz
Product Manager Client Certificates

----------EMAIL

Thanks,

Dick Brooks

Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com
Email: [email-masked]
Tel: +1 978-696-1788

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Friday, June 4, 2021 6:46 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Information model updates

Hi Dick,

> The use case I'm most interested in is not listed in your email. It goes like this:
>
> Customer is notified of a CVE impacting a device in their network. The software supplier makes a patch kit available to address the CVE.
> Customer downloads patch kit and Manifest from a designated location and prepares to do a risk assessment.

I believe that all the information needed to perform the risk assessment is already there. The “customer” in your use case is the same as the “firmware distributor” in the scenario I posed. I fear that my formatting was lost, which made it a bit harder to follow. Maybe I should consider doing some sequence diagrams for this and composing them as a draft for iotops-wg.

> What information will an end use customer need, i.e. manifest and signed sw for sure - any others?) to performs a risk assessment of the patch kit, prior to installation within the affected device, that will achieve the following objectives:
> - Identify the actual software source supplier of the patch kit - VENDOR-ID?

The manifest contains two fields that are of use here. Vendor ID is for ensuring that only compatible firmware is installed. It’s the vendor of the hardware. This is for ensuring compatibility, not authenticity. Identification of the actual source supplier is done via several possible angles:
1. The signer of the manifest.
2. The software vendor, identified in the manifest text section (not delivered to end-devices, only to be used for human inspection) 3. The attached CoSWID (https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid)

CoSWID is optional, but for the use case you describe, I suspect it is necessary.

> - Verify that the digital signature is valid using existing methods 
> for digital signature verification on software objects

This should come after your following point.

> - Verify that the digital signature on the patch kit has been applied 
> by a signing party that has been authorized by the identified software 
> supplier to sign on their behalf

This is the default in SUIT as described previously. SUIT Trust Anchors may not even be available via conventional PKI, so verification by intermediaries MUST be done using explicit Trust Anchors with explicit permissions.

> - Verify that the security patch software contains no malware or known vulnerabilities, using the Manifest and digitally signed software package as inputs, plus any other info that may be needed supplied (e.g. malware attestation).

There are two options for this part:
1. The software vendor attests that a scan has been done and provides metadata. This could be placed in the text section if it is human readable, or it could be added as an extension to SUIT if not.
2. The Firmware Distributor evaluates any third-party endorsements as previously described. These third-party endorsements may be requested by the Firmware Distributor or the manifest may arrive already bearing the third-party endorsements.

Best Regards,
Brendan

>
> Thanks,
>
> Dick Brooks
>
> Never trust software, always verify and report! ™ 
> http://www.reliableenergyanalytics.com
> Email: [email-masked]
> Tel: +1 978-696-1788
>
> -----Original Message-----
> From: Brendan Moran <[email-masked]>
> Sent: Thursday, June 3, 2021 10:15 AM
> To: [email-masked]
> Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
> Subject: Re: [Suit] Information model updates
>
> Hi Dick,
>
>> On 3 Jun 2021, at 12:44, Dick Brooks <[email-masked]> wrote:
>>
>> Hi Brendan,
>>
>> Thank you for that very insightful description of the process – very helpful.
>>
>> The process you describe is clearly the result of methodical thought, analysis and design.
>>
>> However, the small community of SCRM software vendors, including REA, are implementing controls to identify SW risks proactively, prior to any change to the baseline state of a device.
>
> Lets try to be clear about exactly which objectives are achieved by each part of the SUIT Specification and the surrounding entities and protocols.
>
> The SUIT manifest specification is designed, primarily, to be a contract between the Firmware Author and the Recipient. The exact meaning of Firmware Author can be somewhat variable, but ultimately, it means the holder of a private key that is associated with a Trust Anchor known by the Recipient. It’s very much intended that this key be air-gapped, or held in an HSM, not an online signing system, since such platforms instantly become high-value targets for adversaries.
>
> This is explicitly not the same as the relationship between the Firmware Author and the Firmware Distributor, nor the relationship between the Firmware Distributor and the Recipient. There are certain provisions in the manifest to enable those relationships as well.
>
>> Yesterday, Microsoft announced the acquisition of ReFirm Labs, which is one of the SCRM vendors  that performs this type of interrogation of a binary object before any attempt to install or run the software or make any change to the  baseline state of a device.
>> FYI: IMO, Refirm Labs is a trophy catch by Microsoft – Binwalk is the 
>> gold standard for pulling apart a binary to assess its components.
>> Microsoft even produced a cute little video showing how this works – 
>> note everything happens before the SW goes to an IoT device:
>> http://aka.ms/refirmadiotvideo
>>
>> Complete announcement from Microsoft is here:
>> https://www.microsoft.com/security/blog/2021/06/02/microsoft-acquires
>> -
>> refirm-labs-to-enhance-iot-security/
>>
>> IMO, sending the software to a device to make these SCRM risk assessments appears to be in violation of the NERC CIP-010-3 software verification regulation as sending the SW to the device appears to be a change to the device baseline. Others may see this differently.
>
> The manifest is not the software. The manifest is software metadata, security material, and instructions required to install the software. As such, sending a manifest to a device does NOT change the device baseline.
>
> I assume you’re referring to Requirement 1.6 (please clarify if not):
>> Prior to a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5, and when the method to do so is available to the Responsible Entity from the software source:
>> - 1.6.1. Verify the identity of the software source; and
>> - 1.6.2. Verify the integrity of the software obtained from the software source.
>
> This is explicitly how SUIT works. It’s just that the devices are responsible for themselves. Notwithstanding that, SUIT has explicit provisions for enabling an intermediary  to perform pre-deployment checks:
>
> 4.3.19.  REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
>   Manifests SHOULD be verified prior to deployment.  This reduces
>   problems that may arise with devices installing firmware images that
>   damage devices unintentionally.
>
>   Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
>
> https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-mode
> l-12#section-4.3.19
>
>
> In order for an intermediary to evaluate a manifest prior to deployment, they will require certain vital information provided by the Recipient Device, for example Trust Anchors, Vendor ID(s) and Class ID(s). Vendor ID(s) and Class ID(s) are intended to be reported via Attestation as defined in the RATS working group (see here: https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/). Perhaps we should add Trust Anchors to that claim set. There may be some security considerations to reporting those details upwards. This will require careful consideration.
>
>
> Here is the relevant section of the workflow (amended from previous email). Please bear in mind that this likely belongs in the iotops-wg, not suit-wg.
>
>
>
> Logically, every way that we approach this is a de-facto delegation scheme:
>
>        • The Trust Provisioning Authority (TPA) delegates some authority to Trust Anchors (TA) by installing those TAs in the device with some mechanism to specify what permissions they have. Permissions may be, for example:
>                • Authorship rights to individual software components
>                • Authorship rights to groups of components
>                • Qualification Rights (verification that SW works for intended purpose)
>                • Malware Attestation Rights
>                • Distribution Rights (authorisation to override certain parts of a manifest, enabling the Trust Anchor or its delegate to redirect fetches from public to private infrastructure, for example)
>        • Each TA may delegate some or all of its permissions to a subordinate authority (SA)
>        • Each SA may delegate some or all of its permissions to a further SA.
>        • Each SA may sign a manifest.
>
> We have not been prescriptive about the exact mechanism for 1. because there are many, equally valid ways for it to be done. For example, this may be done by:
>        • Installing a TA in a specific location with predefined permissions
>        • Referencing a TA Subject Key Identifier in an Access Control List, signed by the TPA
>        • Signing a TA “certificate” including key usage fields with the TPA’s private key.
>
> Each of these approaches is equally valid and allows a verifier to work backwards from the manifest directly to the TPA, as the ultimate authority.
>
> A Firmware Distributor registers devices:
> Each device registers with the Firmware Distributor The device boots into a secure operating mode The bootloader measures important system parameters (e.g. TAs, Vendor ID(s), Class ID(s), firmware versions, firmware digests) The bootloader signs the system parameters (the Attestation Evidence), then disables the signing key The bootloader hands over to the application/OS The management application connects to the Firmware Distributor and uploads the signed system parameters The Firmware Distributor evaluates each Attestation Evidence:
> It sends the Attestation Evidence to a Verifier.
> The Verifier evaluates the trustworthiness of the Attestation Evidence.
> The Verifier signs the Attestation Evidence, creating an Attestation Report.
> The Verifier returns the Attestation Report to the Firmware Distributor (Relying Party in RATS terminology) Firmware Distributor evaluates the Attestation Report for discrepancies with previous data or out-of-date firmware.
> The Firmware Distributor saves each Attestation Evidence for use in evaluating manifests.
>
> Firmware Creation:
> One SA (a Firmware Author) creates a manifest that describes the 
> installation of a firmware
> Optionally:
> The SA creates a random Content Encryption Key, Initialization Vector The SA encrypts the firmware The SA places the encryption information in the manifest/manifest envelope (TBD).
> The SA places recipient information in the manifest envelope This may 
> include third parties for Third Party Evaluation The SA signs the 
> manifest The SA sends the manifest to a distributor
>
> Optional: Third Party Evaluation. Third Parties may need to evaluate and authorise a manifest independently, for example: Firmware Author’s QA department, Network Operator, Device Operator, Building Manager, Malware Scanning Service. The Third Parties:
> Optional:
> Decrypt the firmware using the encryption info in the manifest/envelope Evaluate the Firmware. For example:
> Test interaction with network
> Test interaction with deployed devices Test for functionality Perform 
> static analysis Scan for known malware Endorse the Firmware:
> The Third Party adds its signature to the manifest.
> NOTE: the Third Party Endorsements are NOT required to work exactly like this. This specification provides one option for third party endorsements. These do not carry documentation about endorsement process with them. That falls outside the scope of the SUIT manifest. An additional specification would be required to define how third party endorsements bearing documents would work, but SUIT could add a container for them.
>
>
> Pre-deployment check. The Firmware Distributor:
> Receives a manifest from the Firmware Author Uses saved attestation information to determine a target set of recipient devices.
> Verifies the authority of the signers: To accomplish this, the verifier is required to:
>        • Verify each delegation chain:
>                • Extract the first delegation CWT, containing the first SA
>                • Verify the CWT against the specified TA
>                • Compute the permissions of the first SA using the TA permissions and the delegation CWT
>                • Extract the next delegation CWT
>                • Verify the CWT against the previous SA
>                • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
>                • If there are more CWTs to process, go to 4, otherwise:
>                • Compute the final SA permissions
>        • Verify the manifest authenticity & authority
>                • Verify each manifest signature against the specified SA (typically the final SA of a chain)
>                • Compute the aggregate manifest permissions:
>                        • This is the union of the permissions of every signer of the manifest.
> Evaluates any endorsements from Third Party Evaluations Validates 
> signatures against authorised third parties Provisioning of trusted 
> third parties into Firmware Distributor infrastructure is out of scope 
> Optionally prunes third-party endorsements prior to distribution (this 
> lowers overhead for the recipients and the network) Validates that 
> manifest applies to target devices (Vendor ID/Class ID matching)
>
>
> The Recipient Device then needs to:
>        • Verify each delegation chain:
>                • Extract the first delegation CWT, containing the first SA
>                • Verify the CWT against the specified TA
>                • Compute the permissions of the first SA using the TA permissions and the delegation CWT
>                • Extract the next delegation CWT
>                • Verify the CWT against the previous SA
>                • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
>                • If there are more CWTs to process, go to 4, otherwise:
>                • Compute the final SA permissions
>        • Verify the manifest authenticity & authority
>                • Verify each manifest signature against the specified SA (typically the final SA of a chain)
>                • Compute the aggregate manifest permissions:
>                        • This is the union of the permissions of every signer of the manifest.
>        • Process the manifest
>                • For each command in the manifest:
>                        • Verify that the manifest has adequate permissions to perform the specified operation on the specified component identifier
>                        • Perform the command
>                • Where a dependency manifest is encountered:
>                        • Dependency permissions are the union of the 
> dependency manifest’s aggregate permissions and all dependent 
> manifests’ aggregate permissions
>
> Hopefully this clarifies the process. I hope that this process is adequate to meet or exceed NERC requirements.
>
> Best Regards,
> Brendan
>
>
>> I believe the SUIT approach for IoT SW updates will work in some 
>> circumstances, e.g. home thermostats, etc. However, I’m not sure it 
>> will fly in cases where devices are operating critical infrastructure 
>> functions, like safety protection systems and Electric Grid controls.
>> I suspect those SW updates will come under “proactive scrutiny” using 
>> SCRM risk assessments before any change to a devices baseline. Just 
>> my
>> .02
>>
>> Thanks,
>>
>> Dick Brooks
>> Never trust software, always verify and report! ™ 
>> http://www.reliableenergyanalytics.com
>> Email: [email-masked]
>> Tel: +1 978-696-1788
>>
>> From: Brendan Moran <[email-masked]>
>> Sent: Thursday, June 3, 2021 7:16 AM
>> To: [email-masked]
>> Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
>> Subject: Re: [Suit] Information model updates
>>
>> Hi Dick,
>>
>> I’m not sure if I’ve answered this in the parallel discussion we were having on malware scan attestation, but I’ll address it here too.
>>
>> Logically, every way that we approach this is a de-facto delegation scheme:
>>
>>      • The Trust Provisioning Authority (TPA) delegates some authority to Trust Anchors (TA) by installing those TAs in the device with some mechanism to specify what permissions they have. Permissions may be, for example:
>>              • Authorship rights to individual software components
>>              • Authorship rights to groups of components
>>              • Qualification Rights (verification that SW works for intended purpose)
>>              • Malware Attestation Rights
>>              • Distribution Rights (authorisation to override certain parts of a manifest, enabling the Trust Anchor or its delegate to redirect fetches from public to private infrastructure, for example)
>>      • Each TA may delegate some or all of its permissions to a subordinate authority (SA)
>>      • Each SA may delegate some or all of its permissions to a further SA.
>>      • Each SA may sign a manifest.
>>
>> We have not been prescriptive about the exact mechanism for 1. because there are many, equally valid ways for it to be done. For example, this may be done by:
>>      • Installing a TA in a specific location with predefined permissions
>>      • Referencing a TA Subject Key Identifier in an Access Control List, signed by the TPA
>>      • Signing a TA “certificate” including key usage fields with the TPA’s private key.
>>
>>
>> Each of these approaches is equally valid and allows a verifier to work backwards from the manifest directly to the TPA, as the ultimate authority.
>>
>> To accomplish this, the verifier is required to:
>>      • Verify each delegation chain:
>>              • Extract the first delegation CWT, containing the first SA
>>              • Verify the CWT against the specified TA
>>              • Compute the permissions of the first SA using the TA permissions and the delegation CWT
>>              • Extract the next delegation CWT
>>              • Verify the CWT against the previous SA
>>              • Compute the permissions of the next SA using the previous SA permissions and the delegation CWT
>>              • If there are more CWTs to process, go to 4, otherwise:
>>              • Compute the final SA permissions
>>      • Verify the manifest authenticity & authority
>>              • Verify each manifest signature against the specified SA (typically the final SA of a chain)
>>              • Compute the aggregate manifest permissions:
>>                      • This is the union of the permissions of every signer of the manifest.
>>      • Process the manifest
>>              • For each command in the manifest:
>>                      • Verify that the manifest has adequate permissions to perform the specified operation on the specified component identifier
>>                      • Perform the command
>>              • Where a dependency manifest is encountered:
>>                      • Dependency permissions are the union of the 
>> dependency manifest’s aggregate permissions and all dependent manifests’ aggregate permissions This enables a full chain of trust with explicit permissions all the way back to the TPA. Hopefully this explains the process. Is there a place that this needs to be more fully explained?
>>
>> Best Regards,
>> Brendan
>>
>>
>>
>>
>>
>>> On 28 May 2021, at 15:59, Dick Brooks <[email-masked]> wrote:
>>>
>>> As I was tracing back the verification process in the Manifest
>>> https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13
>>> https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#se
>>> c
>>> tion-5.2
>>>
>>> This eventually led me to COSE’s Signing and Verification process, which contains the following guidance:
>>>
>>> In addition to performing the signature verification, the application
>>>   may also perform the appropriate checks to ensure that the key is
>>>   correctly paired with the signing identity and that the signing
>>>   identity is authorized before performing actions.
>>>
>>> This is where I hit the dead end – I could not find guidance on the  appropriate checks to ensure that the key is
>>>   correctly paired with the signing identity and that the signing
>>>   identity is authorized before performing actions
>>>
>>> Any insights on what are the appropriate checks would be greatly appreciated. Thanks in advance.
>>>
>>> Thanks,
>>>
>>> Dick Brooks
>>> Never trust software, always verify and report! ™ 
>>> http://www.reliableenergyanalytics.com
>>> Email: [email-masked]
>>> Tel: +1 978-696-1788
>>>
>>> From: Dick Brooks <[email-masked]>
>>> Sent: Friday, May 28, 2021 7:39 AM
>>> To: [email-masked]; 'Russ Housley'
>>> <[email-masked]>
>>> Cc: 'suit' <[email-masked]>; 'Brendan Moran' <[email-masked]>
>>> Subject: RE: [Suit] Information model updates
>>>
>>> Russ and SUIT WG members,
>>>
>>> I’m continuing to research how trust in a digital signature -> software supplier is being established and verified. And I have a question regarding the SUIT architecture.
>>>
>>> The need for validation is made clear in the Architecture:
>>>
>>> Authentication ensures that the device can cryptographically identify the author(s) creating firmware images and manifests. Authenticated identities may be used as input to the authorization process. Not all entities creating and signing manifests have the same permissions. A device needs to determine whether the requested action is indeed covered by the permission of the party that signed the manifest. Informing the device about the permissions of the different parties also happens in an out-of-band fashion and is a duty of the Trust Provisioning Authority.
>>>
>>> I looked further for some guidance on how a Trust Provisioning Authority is expected to ensure that a signing party has received permission to sign a firmware update from the original software supplier. I didn’t find anything in this regard.
>>>
>>> Can you point me to some information regarding the verification steps a TPA is required to implement to ensure that a signing party has been authorized to sign a software object on behalf of the original developer/licensor of a software object?
>>>
>>> It appears the device relies on the TPA’s assertion that a signature on software is indeed authorized and trustworthy without performing any checks on it’s own that this is indeed the case. Is my understanding correct?
>>>
>>> Lastly, what party is expected to perform TPA roles/responsibilities – Certificate Authorities?
>>>
>>> Thanks,
>>>
>>> Dick Brooks
>>> Never trust software, always verify and report! ™ 
>>> http://www.reliableenergyanalytics.com
>>> Email: [email-masked]
>>> Tel: +1 978-696-1788
>>>
>>> From: Dick Brooks <[email-masked]>
>>> Sent: Wednesday, May 26, 2021 7:40 AM
>>> To: [email-masked]; 'Russ Housley'
>>> <[email-masked]>
>>> Cc: 'suit' <[email-masked]>; 'Brendan Moran' <[email-masked]>
>>> Subject: RE: [Suit] Information model updates
>>>
>>> Russ,
>>>
>>> I looked through draft 13 and I didn’t see anything explicit. It 
>>> looks like the information model 
>>> (https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-m
>>> o
>>> del-11#section-4)  touches this subject, but I don’t see any 
>>> materials that explicitly provides guidance regarding: “how to 
>>> verify that a signing party is authorized to sign software 
>>> licensed/produced by party X and is considered a trusted party. “
>>>
>>> This verification step would need to occur during digital signature verification to confirm that the signing party has been authorized to sign software on behalf of party X.
>>>
>>> If you think this is not an appropriate topic for this WG then I can take it off list. Any insights you or the WG can offer is appreciated.
>>>
>>> Please accept my apologies if this is not a proper topic for the suit WG.
>>>
>>> Thanks,
>>>
>>> Dick Brooks
>>> Never trust software, always verify and report! ™ 
>>> http://www.reliableenergyanalytics.com
>>> Email: [email-masked]
>>> Tel: +1 978-696-1788
>>>
>>> From: Suit <[email-masked]> On Behalf Of Dick Brooks
>>> Sent: Tuesday, May 25, 2021 6:13 PM
>>> To: 'Russ Housley' <[email-masked]>
>>> Cc: 'suit' <[email-masked]>; 'Brendan Moran' <[email-masked]>
>>> Subject: Re: [Suit] Information model updates
>>>
>>> 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
>>> Never trust software, always verify and report! ™ 
>>> http://www.reliableenergyanalytics.com
>>> Email: [email-masked]
>>> Tel: +1 978-696-1788
>>>
>>> From: Russ Housley <[email-masked]>
>>> Sent: Tuesday, May 25, 2021 5:22 PM
>>> To: Dick Brooks <[email-masked]>
>>> Cc: suit <[email-masked]>; Brendan Moran <[email-masked]>
>>> 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 <[email-masked]> 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) has received considerable attention since the Cybersecurity Executive order was released on May 12, 2021 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) 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 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
>>>> Never trust software, always verify and report! ™ 
>>>> http://www.reliableenergyanalytics.com
>>>> Email: [email-masked]
>>>> Tel: +1 978-696-1788
>>>>
>>>> From: Russ Housley <[email-masked]>
>>>> Sent: Monday, May 24, 2021 10:14 AM
>>>> To: [email-masked]
>>>> Cc: Brendan Moran <[email-masked]>; suit <[email-masked]>
>>>> 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 <[email-masked]> 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-ch
>>>>> a
>>>>> in-without-sbom
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Dick Brooks
>>>>> Never trust software, always verify and report! ™ 
>>>>> http://www.reliableenergyanalytics.com
>>>>> Email: [email-masked]
>>>>> Tel: +1 978-696-1788
>>>>>
>>>>> From: Suit <[email-masked]> On Behalf Of Russ Housley
>>>>> Sent: Monday, May 24, 2021 9:55 AM
>>>>> To: Brendan Moran <[email-masked]>
>>>>> Cc: suit <[email-masked]>
>>>>> 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 <[email-masked]> 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
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/suit
>>>>>
>>>>> _______________________________________________
>>>>> Suit mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/suit
>>>>
>>>> _______________________________________________
>>>> Suit mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/suit
>>
>> 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.
>
> 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.
>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jun 2021 07:50:46 +0000

Hi Dick,

I agree that just signing software/firmware does not offer much value by itself.

To verify the signature you not only need to have the public key, which may be sent along with the signature of the message, but you also need to trust that public key (via information in the trust anchor store).

Even this might not be enough since you may have many trust anchors and it may not be OK to use any of them to sign your firmware/software.

This is, of course, not a new issue. You just need to look at problems that surfaced related to the WebPKI (see https://datatracker.ietf.org/doc/html/draft-tschofenig-iab-webpki-evolution-01). In that document we, for example, mentioned that "Every CA can issue certificates for any relying party even though that relying party may have never been in a relationship with the issuing CA.". Translated to the concern you are raising: "Every company can sign software even though they have no relationship to the code they are signing (if their trust anchor is in the trust anchor store)."

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Sunday, June 6, 2021 4:22 PM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Friday, June 4, 2021 7:06 AM
To: 'Brendan Moran' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Information model updates

Brendan,

Best,
Seb

Sebastian Schulz

----------EMAIL

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Friday, June 4, 2021 6:46 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Information model updates

Hi Dick,

Best Regards,
Brendan

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 10 Jun 2021 08:47:57 -0400

Thanks, Hannes.

The CAB Forum email that I posted to this list contains a possible solution that will ensure an immutable bonded trust relationship between software supplier and software signer, that is verifiable by a software customer during digital signature verification. A CA operated code signing service is under discussion. More details are needed to determine if this is indeed a solution. 

FYI: I addressed this need, along with other items, in filed comments with NTIA in their call for comments on SBOM requirements in response to the 5/12 Cybersecurity Executive Order.

I'm happy to share my NTIA comments here - but it's a bit lengthy, because it's intended for a government audience, so precision is important. 

Russ, I'll share my NTIA comment filing here, if you give me the green light to do so (about 6 pages in length).

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Thursday, June 10, 2021 3:51 AM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Hi Dick,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Sunday, June 6, 2021 4:22 PM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Friday, June 4, 2021 7:06 AM
To: 'Brendan Moran' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Information model updates

Brendan,

Best,
Seb

Sebastian Schulz

----------EMAIL

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Friday, June 4, 2021 6:46 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Information model updates

Hi Dick,

Best Regards,
Brendan

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jun 2021 12:58:48 +0000

Hi Dick,

I am happy to read your NTIA comments on the SBOM requirements.

I could imagine that the CA Browser Forum is reluctant to deal with such a topic given their current scope. IMHO they are not the audience for code signing. Looking forward to see how code signing services will look like.

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Thursday, June 10, 2021 2:48 PM
To: Hannes Tschofenig <[email-masked]>; Brendan Moran <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks, Hannes.

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Thursday, June 10, 2021 3:51 AM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Hi Dick,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Sunday, June 6, 2021 4:22 PM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Friday, June 4, 2021 7:06 AM
To: 'Brendan Moran' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Information model updates

Brendan,

Best,
Seb

Sebastian Schulz

----------EMAIL

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Friday, June 4, 2021 6:46 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Information model updates

Hi Dick,

Best Regards,
Brendan

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 10 Jun 2021 09:03:46 -0400

Hannes,

The CAB Forum has a code signing work group that specifically addresses code signing practices. 

I'll send my NTIA comments to you privately so as to not bombard the entire work group with unwanted, long (monotonous) emails. 

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Thursday, June 10, 2021 8:59 AM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Hi Dick,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Thursday, June 10, 2021 2:48 PM
To: Hannes Tschofenig <[email-masked]>; Brendan Moran <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks, Hannes.

Thanks,

Dick Brooks

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: Thursday, June 10, 2021 3:51 AM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Hi Dick,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Sunday, June 6, 2021 4:22 PM
To: [email-masked]; Brendan Moran <[email-masked]>
Cc: 'Russ Housley' <[email-masked]>; 'suit' <[email-masked]>
Subject: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Thanks,

Dick Brooks

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Dick Brooks
Sent: Friday, June 4, 2021 7:06 AM
To: 'Brendan Moran' <[email-masked]>
Cc: 'suit' <[email-masked]>; 'Russ Housley' <[email-masked]>
Subject: Re: [Suit] Information model updates

Brendan,

Best,
Seb

Sebastian Schulz

----------EMAIL

Thanks,

Dick Brooks

-----Original Message-----
From: Brendan Moran <[email-masked]>
Sent: Friday, June 4, 2021 6:46 AM
To: Dick Brooks <[email-masked]>
Cc: Russ Housley <[email-masked]>; suit <[email-masked]>
Subject: Re: [Suit] Information model updates

Hi Dick,

Best Regards,
Brendan

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Jun 2021 17:41:10 -0400

> Russ, I'll share my NTIA comment filing here, if you give me the green light to do so (about 6 pages in length).

Can you post it on a website, and then post a pointer here?

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Jun 2021 18:22:12 -0400

I strongly disagree. Given my history of involvement in the WebPKI, I am
certainly not biased against CAs. My concern is different.

I see multiple concerns:

1) Every software distribution MUST be signed without exception

2) All software executables and data installed on a machine MUST be signed
by the provider.

3) All signatures MUST be under keys that have a trustworthy credential.

The reason I reject (3) is because I insist on (1) and (2). I want every
piece of software to be signed on every machine without any exception
whatsoever. That includes every development build, every open source
project, every script written by the user. And that should apply to every
desktop, laptop, tablet, mobile etc.

Thing is that I can't have the strong signing model I want if I also insist
that every credential be an EV signature. It is one or the other. I choose
everything signed.

For critical infrastructure devices, I suggest the following:

0) Must identify such machines and label them prominently

1) Software must be signed under trustworthy credential

2) Platform must verify signature before executable is launched.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Jun 2021 06:34:04 +0000

Hi Phil,

a few clarifying questions.

  *   What is a “trustworthy credential” for you?
  *   Who is the “provider” here?
  *   What do you mean by “Must identify such machines”? Are you saying that the software / firmware update must identity the machine it applies to?
  *   When you say “Every software distribution MUST be signed without exception” are you trying to distinguish between the signing the software vs. securing the distribution? With regards to the exception you are not talking about what happens during manufacturing.

Ciao
Hannes

From: Phillip Hallam-Baker <[email-masked]>
Sent: Friday, June 11, 2021 12:22 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]; Brendan Moran <[email-masked]>; suit <[email-masked]>; Russ Housley <[email-masked]>
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

I strongly disagree. Given my history of involvement in the WebPKI, I am certainly not biased against CAs. My concern is different.

I see multiple concerns:

2) All software executables and data installed on a machine MUST be signed by the provider.

The reason I reject (3) is because I insist on (1) and (2). I want every piece of software to be signed on every machine without any exception whatsoever. That includes every development build, every open source project, every script written by the user. And that should apply to every desktop, laptop, tablet, mobile etc.

Thing is that I can't have the strong signing model I want if I also insist that every credential be an EV signature. It is one or the other. I choose everything signed.

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 11 Jun 2021 06:58:55 -0400

+1 “What is a “trustworthy credential” for you? “

And, most importantly from a SCRM perspective, how can a software consumer verify the trustworthiness of a software package, before installation, having only a signed, binary distribution of the software package in hand?

Thanks,

Dick Brooks

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

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

Email: [email-masked] <mailto:[email-masked]> 

Tel: +1 978-696-1788

From: Hannes Tschofenig <[email-masked]> 
Sent: Friday, June 11, 2021 2:34 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]; Brendan Moran <[email-masked]>; suit <[email-masked]>; Russ Housley <[email-masked]>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Hi Phil, 

Ciao

Hannes

From: Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, June 11, 2021 12:22 AM
To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Brendan Moran <[email-masked] <mailto:[email-masked]> >; suit <[email-masked] <mailto:[email-masked]> >; Russ Housley <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

I see multiple concerns:

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 11 Jun 2021 07:14:17 -0400

Done.

https://github.com/rjb4standards/REA-Products/blob/master/20210608-NTIAFiled
Comments.pdf

Thanks,

Dick Brooks

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

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

Email:  <mailto:[email-masked]>
[email-masked]

Tel: +1 978-696-1788

From: Russ Housley <[email-masked]> 
Sent: Thursday, June 10, 2021 5:41 PM
To: Dick Brooks <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Surprising push back on the need for a customer to
verify the trust relationship between a software supplier and software
signer during digital signature validation on signed code

Dick:

Russ, I'll share my NTIA comment filing here, if you give me the green light
to do so (about 6 pages in length).

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2021 14:39:11 -0400

On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <[email-masked]>
wrote:

>    - What is a “trustworthy credential” for you?
>    - Who is the “provider” here?
>    - What do you mean by “Must identify such machines”? Are you saying
>    that the software / firmware update must identity the machine it applies to?
>    - When you say “Every software distribution MUST be signed without
>    exception” are you trying to distinguish between the signing the software
>    vs. securing the distribution? With regards to the exception you are not
>    talking about what happens during manufacturing.
>
>
I am distinguishing between Sign ( Zip (files) , k) and Sign (files, k).

Authenticode only signed the software distribution package, most of what
has followed has done the same. That is a useful control of course because
an installer is an executable that runs on the machine. But it is necessary
but not sufficient: Every executable, every piece of installed data should
be signed without exception.

On the other issues, well it totally depends on your application and your
regulator. In the aftermath of Diginotar we had a lot of discussions of
what should be subject to audit. My position was that is actually something
the CA decides. Basically, the CA can define their boundary to be anywhere
they like, that is purely a matter for them to decide.

The catch here is that if you are going to show that your practices meet
your policy, then you have to show that all your cert issuing machinery is
subject to audit. Contrawise, the more of your machinery you stick within
the audit boundary, the harder time you are going to have showing it is
secure.

I would apply the same approach here. The pipeline provider etc. has to
show that its operations are secure. I am not going to write a list of what
they have to pur inside or outside of their security perimeter, I am merely
saying that they have to define one, they have to show that all the
necessary operations are inside it and that everything inside it is
sufficiently secure.

If we are talking about a pipeline then CABForum EV certs are probably
sufficient. For civil nuclear, I would consider that a starting point, I
would want all software to be signed under a cert that was individually
enumerated and credentialed.

It is worth pointing out that the reason colonial pipeline was affected so
badly was probably that they were sending multiple types of fuel down the
same pipe in batches. That game is only going to work if you can absolutely
guarantee that you aren't going to put the load of tar into a tank full of
top grade aviation fuel. So their problem probably wasn't on their actual
operations side itself, the thing they were looking at. They had not
understood that the database of what fuel is where was actually critical to
operations.

On provider, I am being deliberately vague because sometimes the provider
is going to be the developer, other times it isn't. A large amount of
Ubuntu packages are signed by the people who are putting the packages
together who are not the actual developer. This third party work does have
value in that there is a curation process going on there and it is possible
to imagine mechanisms whereby detected insertion of malware could be
revoked. But we don't have those at this point of course.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Jun 2021 12:12:18 -0700

Maybe this an operational, marketplace, policy and certification issue that is often use-case specific?

Apple decided that everything on an iPhone is signed and manages the ecosystem

Google did the same, but a little different.

Certification of FIDO authenticators at higher levels requires SW be under control of the authenticator vendor with signing being a good way to do it.

Maybe GlobalPlatform should run an TEEP certification program that requires signing.

Individual industries, like automotive, industrial infrastructure and such can come up with their operation requirements and/or certification programs.

Maybe Linus can say how signing should work on Linux and get enough momentum to make it happen.

It seems hard for an organization like IETF to know the details of all the use cases and to have enough leverage to make this happen. It doesn’t seem that effective to try to put policy into security considerations.

LL

> On Jun 11, 2021, at 11:39 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Phil, 
> 
>  
> 
> What is a “trustworthy credential” for you?
> Who is the “provider” here?
> What do you mean by “Must identify such machines”? Are you saying that the software / firmware update must identity the machine it applies to?
> When you say “Every software distribution MUST be signed without exception” are you trying to distinguish between the signing the software vs. securing the distribution? With regards to the exception you are not talking about what happens during manufacturing.
> 
> Authenticode only signed the software distribution package, most of what has followed has done the same. That is a useful control of course because an installer is an executable that runs on the machine. But it is necessary but not sufficient: Every executable, every piece of installed data should be signed without exception.
> 
> On the other issues, well it totally depends on your application and your regulator. In the aftermath of Diginotar we had a lot of discussions of what should be subject to audit. My position was that is actually something the CA decides. Basically, the CA can define their boundary to be anywhere they like, that is purely a matter for them to decide. 
> 
> The catch here is that if you are going to show that your practices meet your policy, then you have to show that all your cert issuing machinery is subject to audit. Contrawise, the more of your machinery you stick within the audit boundary, the harder time you are going to have showing it is secure.
> 
> I would apply the same approach here. The pipeline provider etc. has to show that its operations are secure. I am not going to write a list of what they have to pur inside or outside of their security perimeter, I am merely saying that they have to define one, they have to show that all the necessary operations are inside it and that everything inside it is sufficiently secure.
> 
> If we are talking about a pipeline then CABForum EV certs are probably sufficient. For civil nuclear, I would consider that a starting point, I would want all software to be signed under a cert that was individually enumerated and credentialed. 
> 
> It is worth pointing out that the reason colonial pipeline was affected so badly was probably that they were sending multiple types of fuel down the same pipe in batches. That game is only going to work if you can absolutely guarantee that you aren't going to put the load of tar into a tank full of top grade aviation fuel. So their problem probably wasn't on their actual operations side itself, the thing they were looking at. They had not understood that the database of what fuel is where was actually critical to operations.
> 
> 
> On provider, I am being deliberately vague because sometimes the provider is going to be the developer, other times it isn't. A large amount of Ubuntu packages are signed by the people who are putting the packages together who are not the actual developer. This third party work does have value in that there is a curation process going on there and it is possible to imagine mechanisms whereby detected insertion of malware could be revoked. But we don't have those at this point of course.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Jun 2021 18:42:01 -0400

> The reason I reject (3) is because I insist on (1) and (2). I want

I'm with you here, and I agree with your compromise situation.

    > 2) Platform must verify signature before executable is launched.

So you make a distinction between software executables installed on a machine
(above), and "launched" here.   I wanted to be sure that this distinction was
intended.

We have in the past discussed the question of who controls the trust anchor
authorized to perform software updates in a given system.   
That's to be distinguished from who signs the software!

One of the limitations in the Android ecosystem is that one has only two
choices:  trust Google, allow unsigned executables (APKs).   An intermediate choice
could be, "trust anchor FOO".  Trusting more than one gets us into the WebPKI
problem of who is authorized for what, and cert transparency, etc.
Apple does slightly better in that (I understand) Apple insists that all
packages be signed, but allows for some people (developers) to designate
certain phones are allowed to trust the local enterprise.  This doesn't scale
to the general public though.

In the industrial IoT space, I think that operators will want to be the
ultimate authority as to what code runs where.  So the authorized trust
anchor in the device will not be the manufacturer, but the operator.
The operator will verify the signature(s) from the manufacturer of the
software, and then will countersign or resign the MANIFEST with their key.

How this will play out in other spaces, I don't know exactly.
I expect *Tesla* to sign the code in the brake MCU, not Bosch, even though
Bosch made it.  That doesn't mean that Bosch didn't sign the code when it was
transfered to them.  Unfortunately, I don't think the car owner will get to
decide.  How that will play out when the manufacturer declares EOL, I don't
know.  (I have a 30yr old VW.  But, it's a toy, not transport. I use bike +
transit in town)

There will be some equipment which, when the manufacturer says EOL, then the
device needs to die.  There will be other things where this is less important.

What can the IETF do?  Well, I think that we (SUIT WG) needs to consider how
to manage and update authorizations for trust anchors in a standardized way.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Jun 2021 18:49:56 -0400

Phillip Hallam-Baker <[email-masked]> wrote:
    > Authenticode only signed the software distribution package, most of
    > what has followed has done the same. That is a useful control of course
    > because an installer is an executable that runs on the machine. But it
    > is necessary but not sufficient: Every executable, every piece of
    > installed data should be signed without exception.

I think that there are existing mechanisms to embed signatures in ELF.
There was a lot of discussion, I think, about how the signature was visible
or not visible to regular tools.  Some mechanisms basically hid the signature
at the end of the file, pretending that the file was shorter when treated as
an executable.
Other people wanted it in some other resource record, but then there were
concerns that the signatures would get lost in backups, etc.

So there have been patches to Linux to verify the signatures before
executing.  I think that this has been done on other platforms, and there are
even MCUs that can verify and even decrypt code transparently as it is executable.

Are you thinking at this level?   Always?  Sometimes?

    > am merely saying that they have to define one, they have to show that
    > all the necessary operations are inside it and that everything inside
    > it is sufficiently secure.

I think that there is an additional part: resilience of the whole to failures
of the pieces.   Having one large perimeter is not as good as having many
small ones, except some consideration of economies of scale.

...

    > It is worth pointing out that the reason colonial pipeline was affected
    > so badly was probably that they were sending multiple types of fuel
    > down the same pipe in batches. That game is only going to work if you
    > can absolutely guarantee that you aren't going to put the load of tar
    > into a tank full of top grade aviation fuel. So their problem probably
    > wasn't on their actual operations side itself, the thing they were
    > looking at. They had not understood that the database of what fuel is
    > where was actually critical to operations.

So that was really their problem, they lost their inventory list?

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 12 Jun 2021 01:19:07 +0200

Phil,

a) Let me see if i get your high level point correctly and/or expand correctly:

   - We want signatures on all pieces of software/data loaded onto systems.
     These signatures allow to authenticate who (signer) says what
     about the signed software/data. Not sure if there is a framework
     for the "what" there is, but i could think of more "what" than
     just an implied "authentic" binary flag implied by the presence of
     the signature.
   - What to make out of those signatures should be different policy decision. 
     As in: just because its signed doesn't mean i trust the software to run
     on my system. Trust policies depend on signatures but would embody
     additional critera such as specific CA for specific software purposes
     or the like.

b)  Wrt to CA policy freedom (" Basically, the CA can define their boundary
    to be anywhere they like, that is purely a matter for them to decide")

    This reminds me a bit of ISO9000 and how uneducated customers are. As in:
    There can be thousands of software companies out there that customers
    trust to be reliable because the software company is ISO9000 certified,
    and none of those customers ever looked up what that means.

    As in "Our software company ISO-9000 process: before we start coding,
    every day, we dance on the tables and drink 3 beers to get into the mood.
    End of ISO-9000 process". The ISO-9000 auditors also got free beers,
    everyone was happy. Worst part: that process might lead to more reliable
    software than some other ISO-9000 audits i have seen.

    Aka: I don't think you get around having some standards for the
    security boundary you describe and whoever defines that boundary/audit
    standard could make nice money from e.g. also getting involved
    into the software signing.

Cheers
    Toerless

On Fri, Jun 11, 2021 at 02:39:11PM -0400, Phillip Hallam-Baker wrote:
> >    - What is a ???trustworthy credential??? for you?
> >    - Who is the ???provider??? here?
> >    - What do you mean by ???Must identify such machines???? Are you saying
> >    - When you say ???Every software distribution MUST be signed without
> >    exception??? are you trying to distinguish between the signing the software

-- 
---
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2021 19:31:14 -0400

> Are you thinking at this level?   Always?  Sometimes?

Given that this is a submission to govt. I am not particularly concerned
with the normal process of socializing a proposal in the Linux proposal.

This is the sort of area where if govt. sets a specific, achievable
requirement and puts up a relatively modest amount of cash, change is going
to happen. And don't forget that the reason Ubuntu exists in the first
place is that Mark Shuttleworth (appropriately) had a bee in his bonnet
about code signing. I really don't see this as a heavy lift

The harder part is all the checking and certification that has to take
place in order to know that a theoretical security control is an actual
one. It takes quite a bit to make something the default. But this is
something that a lot of parties have interests that could be met at the
same time.

Take Java and .NET code. Both require a runtime library support to run.
Both seek to provide cross platform binary compatibility. Wouldn't it be
nice if there was an industry standard agreement on one packaging format
for an executable that will work on Windows, Linux and MacOS on any CPU?

If we want to get really serious, we will need hardware support so that
file digests are checked as pages are mapped into memory.

> small ones, except some consideration of economies of scale.

Yes, and I am happy to leave that part of the problem to those concerned
with specific deployments.

> So that was really their problem, they lost their inventory list?

That is my informed guess after reviewing some non public info and reading
between the lines in various communications.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2021 20:18:03 -0400

When writing a specification, it is always important to decide on what
problems you intend to solve and which you plan to leave for others.

Unauthenticated signatures have real proven value in anti-Virus protection.
As Marcus Rannum argued over a decade ago, looking for badness is a failing
strategy because the badness is infinite. If every copy of Adobe software
is signed with a software key that chains to a self signed cert created by
adobe, that provides a vast amount of leverage for AV systems even without
TTP validation.

That is not a theoretical approach, it is precisely how Comodo Default Deny
Protection (TM) works. If you build databases of signatures of known good
software, spotting the bad or the corrupted software is much easier.

That is why I want all software signed without exception. If you try to
gate software signing on a CA issued key you are making exactly the same
mistake that keeps S/MIME at 0.00001% of email traffic. As I argued in the
SSL cert space since 2000 or so, Web browsers should accept self-signed
certificates without complaint or notification to the user. Just drop the
padlock icon telling them the site is secure.

I don't think that the answer to the problem of validation is to set up a
mickey mouse CA that provides certificates without any validation of
organization existence, accountability, proof of right, etc. giving out
rubbish certs for free. Gresham's law applied to the WebPKI: the bad certs
drive out the good. If you try to make CA issued certs mandatory, someone
will come along and reduce the issue criteria to the point where they have
no value over self-signed.

Yes, I am proposing a callsign registry that could be adapted to code
signing. But to be honest, that is not one of the primary motivations for
it nor is it something I have given a lot of thought to in the design of
callsign.

My rough notion is this: @alice, @bob, @carol work for @threshold As they
are developing code, every build they create is signed under their personal
software developer key bound to their Mesh profile by means of a connection
assertion and thus their callsign. So Alice isn't going to run any
developer build not signed by any of the three of them.

When it comes to the general public trusting the signature, they are not
going to know Alice or Bob or Carol and they probably don't know Threshold
so the call sign alone really isn't enough to convince J. Random User to
install and run it. So @Threshold gets a TTP validation of their key and
that is maybe gated so that two out of the three of them have to sign.

On Fri, Jun 11, 2021 at 7:19 PM Toerless Eckert <[email-masked]> wrote:

> so

---

From: "Dick Brooks" <[email-masked]>
Date: Sat, 12 Jun 2021 07:08:59 -0400

There are two distinctly different use cases (schemes) where digital signatures are used today in the Energy industry:

1.	Peer-Peer trust using PGP keys and private exchange/verification (Natural Gas)
2.	CA issued X.509 certificates, where no a-priori trust relationship exists and a trusted 3rd party provides the trust needed to link the identity tied with the key pair via a certificate

Both approaches work well to satisfy the trustworthiness “bar” needed to conduct a business transaction.

Phillip, I agree: All software MUST be signed, by a trustworthy party that has been authorized to sign software on behalf of the authorized software supplier/licensor, which a software customer can verify as part of digital signature verification. 

This can work under both schemes, IF:

*	The signing credentials can be trusted, meaning the customer has a way to verify trust using scheme 1 or 2
*	The signature on software can be trusted, meaning the customer has a method to verify that the signature uses a trusted credential, and now for the hard part, the customer can verify that the signing party has been authorized by a software supplier to sign code on their behalf, under schemes 1 and 2. This can happen with scheme 1, but I don’t see how this can happen with scheme 2 without supporting infrastructure, that doesn’t seem to exist today. 

Thanks,

Dick Brooks

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

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

Email:  <mailto:[email-masked]> [email-masked]

Tel: +1 978-696-1788

From: Phillip Hallam-Baker <[email-masked]> 
Sent: Friday, June 11, 2021 8:18 PM
To: Toerless Eckert <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; suit <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]; Brendan Moran <[email-masked]>
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

When writing a specification, it is always important to decide on what problems you intend to solve and which you plan to leave for others.

Unauthenticated signatures have real proven value in anti-Virus protection. As Marcus Rannum argued over a decade ago, looking for badness is a failing strategy because the badness is infinite. If every copy of Adobe software is signed with a software key that chains to a self signed cert created by adobe, that provides a vast amount of leverage for AV systems even without TTP validation.

That is not a theoretical approach, it is precisely how Comodo Default Deny Protection (TM) works. If you build databases of signatures of known good software, spotting the bad or the corrupted software is much easier. 

That is why I want all software signed without exception. If you try to gate software signing on a CA issued key you are making exactly the same mistake that keeps S/MIME at 0.00001% of email traffic. As I argued in the SSL cert space since 2000 or so, Web browsers should accept self-signed certificates without complaint or notification to the user. Just drop the padlock icon telling them the site is secure. 

I don't think that the answer to the problem of validation is to set up a mickey mouse CA that provides certificates without any validation of organization existence, accountability, proof of right, etc. giving out rubbish certs for free. Gresham's law applied to the WebPKI: the bad certs drive out the good. If you try to make CA issued certs mandatory, someone will come along and reduce the issue criteria to the point where they have no value over self-signed.

Yes, I am proposing a callsign registry that could be adapted to code signing. But to be honest, that is not one of the primary motivations for it nor is it something I have given a lot of thought to in the design of callsign.

My rough notion is this: @alice, @bob, @carol work for @threshold As they are developing code, every build they create is signed under their personal software developer key bound to their Mesh profile by means of a connection assertion and thus their callsign. So Alice isn't going to run any developer build not signed by any of the three of them.

When it comes to the general public trusting the signature, they are not going to know Alice or Bob or Carol and they probably don't know Threshold so the call sign alone really isn't enough to convince J. Random User to install and run it. So @Threshold gets a TTP validation of their key and that is maybe gated so that two out of the three of them have to sign. 

On Fri, Jun 11, 2021 at 7:19 PM Toerless Eckert <[email-masked] <mailto:[email-masked]> > wrote:

Phil,

Cheers
    Toerless

On Fri, Jun 11, 2021 at 02:39:11PM -0400, Phillip Hallam-Baker wrote:
> On Fri, Jun 11, 2021 at 2:34 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
> wrote:
> 
> > Hi Phil,
> >
> >
> >

-- 
---
[email-masked] <mailto:[email-masked]>