Re: [Rats] disposition of remaining pull requests to architecture document

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

See my comments inline beginning with NMS>.

On 9/11/20, 10:33 AM, "RATS on behalf of Laurence Lundblade" <[e-mail] on behalf of [e-mail]> wrote:

    > 
    > Dear WG chairs, WGLC soon?

    I have two open issues against section 7 that I think are important. I generally think section 7 needs a fair bit of work. 

    One of the issues with it is intermingling primary trust flow vs the secondary trust flow. 

NNS> The objective of this section is to highlight the potential for trust semantics to occur in both directions. I think this is what your mean by 'primary' and 'secondary' trust flow? It isn't trying to exhaustively describe the various nuances of how a protocol or implementation might resolve the tension. 

	Primary trust flow is about the RP trusting the Attesters, the main point of attestation. Secondary is primarily about confidentiality while achieving the primary goal of attestation. I think every subsection of section 7 needs to address both and be clear which it is addressing when it does. 

NMS> I think it may not be possible to achieve full clarity outside the context of a particular protocol. So this may be a case where less is more. It already points out that confidentiality protection may be needed if attested values are privacy sensitive. That implies there is some basis for trusting confidentiality keys (which possibly already exists in a given context or protocol). The arch draft should be careful not to bias toward a particular confidentiality technique or technology IMO. 

	I think TLS is good enough for the confidentiality in the secondary trust flow; attestation can be used, but is not needed.

NMS> I don't think it is an intention of the architecture to identify or recommend any particular solution for confidentiality protection.

    The other issue with section 7 is that I think it needs to say that Verifier trust in an Attester is almost always about attestation keys and that is it transitive through the Endorser. The only case where it is not is when they are connected by trusted HW, for example on the same bus, and that is usually not the reason to deploy attestation.


NMS> Words like "almost always" and "usually" are problematic because future use can change from current use rendering the architecture document content qualified in this way to become biased against whatever becomes common practice. If these words are omitted, does the recommendation in the above two sentences still make sense? 

Unpacking this a bit more:
"Verifier trust in an Attester is about attestation keys"
This is correct but too narrow as attestation is also about claims related to the environments that process other functions and protect other objects besides keys.

"[attestation of keys] is transitive through the Endorser"
This may be true if certain conditions also exist such as whether or not the key existed at the time of manufacturing such that the Endorser is able to make a claim about it. However, some hardware doesn't allow the Endorser to know the key or keys are not yet created at the time the Endorser is in possession of the device. The claims the Endorser supplies will have semantics that reflects these nuanced differences.

"The only case where it is not is when they are connected by trusted HW, ..., not the reason to deploy attestation"
I disagree with this characterization - of when it is not appropriate to do attestation. 


    Also, I think the distinction between Attestation and TLS/HTTPS needs to be described in the document. Say why we need Attestation given we have TLS.

NMS> The architecture is trying not to endorse or specify a particular conveyance mechanism / protocol whether for moving around attestation messages or for providing confidentiality protections. This distinction seems to be clearly made in the sections on conveyance and messages. If we begin listing protocols that could be used for conveyance we have to ask when we should stop listing them and what it means if we happen to exclude one. 

If the assertion you're making is that TLS and protocols on top of it such as HTTPS are already implementing attestation conveyance then that seems incorrect as existing standards don't describe how Evidence is conveyed. There may be several ways to tunnel Evidence through TLS handshake or layer on top using extensions to HTTPS, or claims are conveyed as Endorsements / Reference values etc. but a draft explaining how to do this is warranted. It seems inappropriate for the arch draft to do it. 

-Ned