Re: [Rats] [Suit] [sacm] CoSWID and EAT and CWT

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

On 12/3/19, 1:08 PM, "Suit on behalf of Michael Richardson" <[e-mail] on behalf of [e-mail]> wrote:

    
    
    Smith, Ned <[e-mail]> wrote:
        > I'm not clear if you are saying that an unsigned CoSWID is assumed to
        > be a statement from an Attest-ING environment or something
        > else. Normally, I regard unsigned assertions as invalid (verifiers
        > should not make assumptions).
    
    I believe that unsigned CoSWID structures will be inside another signed
    structure (such as a SUIT manifest), will be conveyed by secure transport
    (i.e. HTTPS or CoAPS transport of a RESTCONF mechanism that retrieves it), or
    will be stored in a trusted database.
    
    So, I agree with you that unsigned CoSWID objects in the wild would be
    invalid and unusual.
[nms] The unsigned CoSWID that is enveloped by something else that is signed may not be the same as a CoSWID that is (directly) signed because the signing keys could differ. The Verifier should care not only about who asserts the CoSWID but also whether or not that entity is authorized (most authoritative entity) to make the assertion. Even if some other layer 'signs' it, it could still be invalid.
    
        > CoSWID structures can be signed by either Attesters (Attesting env) or
        > Endorsers. The CoSWID formatting is the same but the signers are
        > different and a Verifier might treat the CoSWID content differently
        > based on who signed it. For example, if an Attester signed it then a
        > Verifier would expect to find an Endorser signed CoSWID with which to
        > compare to Evidence.
    
    I'm a bit uncomfortable with the idea that a CoSWID signed by an Attester is
    the way that an Attester indicates what software release it is running.
    I would prefer that the structure was instead:
       EAT{protected_map{measurement-of-running-firmware=XX}
           S_endorser{firmware_version=YY,measurement=XX}}
    
    That is, the CoSWID provided by as part of the Evidence would echo the
    Endorsement. Of course, the Verifier would still have to be able to verify
    the endorser's key, but having done so, it now can consider the policy
    question: "is firmware_version YY new enough?"

[nms] Agree. CoSWID is good at saying M=(S_endorser{firmware_version=YY,measurement=XX}). Verifier doesn't necessarily care if M arrives as an EAT map (above) or some other way. Verifier might care that Attester knew that measurement-of-running-firmware matches M if Attester is also doing Verified Boot or is trusted in some way to make sure XXs match. Simply constructing the map doesn't imply the Attester did the other checks unless there is a specification that mandates the check as a condition of forming the map structure.
    
        > Enveloping formats (e.g. EAT[CoSWID] ) doesn't disambiguate who signed
        > what. Both the EAT thing and the CoSWID thing could be signed and by
        > different signers. Alternatively, neither of them could be signed. If
        > the latter, then both the EAT and CoSWID things are invalid.
    
    I think that we are in violent agreement here.
    
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
    
    
    --
    Michael Richardson <[e-mail]>, Sandelman Software Works
     -= IPv6 IoT consulting =-