You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It the current teep-protocol, probably it is assumed that the uri of TC is encapsulated inside SUIT_Envelope, so the uri portion is signed by the TC signer and TAM can not change the uri.
This concept is perfectly legitimate when TC signer knows the uri before creating the suit-manifest, and the business model of TAM and TC signer is tightly coupled.
If we could make uri independent from the TC signer, it will provide more wider range of use cases for the teep-protocol.
For example, considering a device manufacture who is a TC singer generates TCs and the suit-manifests and asking many different server vendors to host there TCs. It would be good if the manufacture do not have to generate many different suit-manifests each time for different server vendors with different uris.
Also, if the TAM vendor uses cdn or load balancer for hosting the TCs then the TAM vendors would like to select appropriate uri by TAM's decision.
Even the uri is not signed by TC signer, the rest of suit-manifest is signed by TC signer, and the device could validate the TC regardless of which uri the TC came from.
What the device would like to able to do in teep-protocol is even having the uri out of the scope of TC signer, the device could verify the TC binary by the digest of the binary and the TC's signature inside suit-manifest.
Would the current SUIT supports having another uri outside of TC signer area as following?
SUIT_Envelope = {
suit-authentication-wrapper,
suit-manifest : {
suit-common : {
suit-common-sequence : {
suit-directive-override-parameters : {
image-sigest : ["sha256", '0xF00'],
uri : 'http://example.com/overridden_tc_signed'
}
}
},
suit-install : {
directive-set-parameters : {
uri : 'http://example.com/original_tc_signed'
}
}
},
//XXX: TAM want to modify URIs below even after tc-signer signed suit-manifest above.
suit-install : {
suit-directive-set-parameters : {
uri : 'http://example.com/a_not_tc_signed'
},
suit-directive-try-each : [
{
directive-set-parameters : {
uri : 'http://cdn.com/b_not_tc_signed'
}
},
{
directive-set-parameters : {
uri : 'http://vendor.com/c_not_tc_signed'
}
}
]
}
}
If the above is fine, then we may not have to change anything in teep.
The text was updated successfully, but these errors were encountered:
It the current teep-protocol, probably it is assumed that the uri of TC is encapsulated inside SUIT_Envelope, so the uri portion is signed by the TC signer and TAM can not change the uri.
This concept is perfectly legitimate when TC signer knows the uri before creating the suit-manifest, and the business model of TAM and TC signer is tightly coupled.
If we could make uri independent from the TC signer, it will provide more wider range of use cases for the teep-protocol.
For example, considering a device manufacture who is a TC singer generates TCs and the suit-manifests and asking many different server vendors to host there TCs. It would be good if the manufacture do not have to generate many different suit-manifests each time for different server vendors with different uris.
Also, if the TAM vendor uses cdn or load balancer for hosting the TCs then the TAM vendors would like to select appropriate uri by TAM's decision.
Even the uri is not signed by TC signer, the rest of suit-manifest is signed by TC signer, and the device could validate the TC regardless of which uri the TC came from.
What the device would like to able to do in teep-protocol is even having the uri out of the scope of TC signer, the device could verify the TC binary by the digest of the binary and the TC's signature inside suit-manifest.
Would the current SUIT supports having another uri outside of TC signer area as following?
If the above is fine, then we may not have to change anything in teep.
The text was updated successfully, but these errors were encountered: