Re: [Rats] Supply Chain Attestation (was Re: 3 Use cases)

["Smith, Ned" <[e-mail]>]

There seems to be consensus around the idea that the entity implementing the Attester role can be decomposed into at least two components the "Attesting Environment" and "Attested Environment". 

If the component architecture allows for an Attested Environment to become an Attesting Environment then it seems possible to talk about various component architectures. If the goal is to be prescriptive, then I'll suggest a couple possibilities (prescriptions?) that can be described in terms of Attesting and Attested terms. 

- Multi-Component Package (MCP) where components may/may not have the ability to be an Attesting Environment all of them can be an Attested environment. 
- Software loading and execution such as a boot sequence or an OS load / exec scenario. It is possible that each software module exists as an Attested Environment (ingredient?) until it receives an execution thread after which it may become an Attesting Environment if the software loaded contained attestation functionality. 

Does this help?

-Ned

On 12/5/19, 10:07 AM, "RATS on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

    
    Cleaning my inbox out, leads me to a thread I felt needed some love.
    
    I think that Ned Smith wrote:
        > I think there are 3 classes of nesting logic:
    
        > 1 Subcomponent(s) that are Attested by a parent component (single layer
        > attestation of a multi-layered decomposition)
        > 2 Subcomponent(s) that are Attested by a parent component and Attesting
        > other subcomponents (layered attestations)
        > 3 Subcomponent(s) that are Attested by more than one parent component
        > (e.g. countersigned or co-signed)
    
    Kathleen Moriarty <[e-mail]> wrote:
        > If you are just talking about the TEE case and not the manufacturer signing
        > use case, then the signatures do build from the base. But for what I would
        > call supply chain, the manufacturer or software developing organization is
        > the one to provide the signature and they know what software, modules. or
        > components they rely upon. Therefore, the 3 classes are not painting the
        > right picture for what I would call the supply chain use case. That's why
        > your nesting module looks different than what I stated, where I was talking
        > about what you are calling "endorsements'.
    
    I am not sure if we have resolved this.
    I think that we continue to have challenges with describing the component situation.
    I suspect that what we need to do is to be somewhat prescriptive here, rather
    than trying to make everyone happy with a single diagram.
    
    --
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-