Draft: draft-ietf-rats-architecture

Commentary: possible text closing . 
 The architecture draft should say that known - good reference values can be either a part of an endorsement or part of an appraisal policy or both . 
 I would only want to mention " known - good reference values " at all if it comes with an explanation of why they 're not sufficient in the real world . Not sure whether we want the arch doc to go there . We can discuss in a meeting . 
 I would n't say they are never sufficient . I would say KGVs serve a specific purpose . And this purpose is documenting the successful loading of well - known software on well - known Attester equipment , where the Attester equipment supports the signing of extended / hashed measurements . Adding Guy / Ned as they probably have better words for this based on their work with TCG & DICE .     ,  , I 'd just add one more restriction to the list ... if " known good values " means " if the measured hash in a PCR is exactly this value then we 're good " , the domain has to be narrowed to single - threaded well - known software instances , e.g. , the components of a BIOS . The complexity of known - good - values comes with asynchronous threads such as IMA in Linux ; in that case , the hash in the TPM PCR can only serve as a check on the ( perhaps huge ) number of individual hashes in the log file , each of which needs its own Known Good Value . Hence the SWID tags . I 'm certainly not qualified to say how all this would work in EAT- or TEEP - land ... /guy Juniper Business Use Only 
 Going back to Laurence ’s original request . The observation he is making is that both the Endorser and the Appraisal Policy for Evidence Owner entities can say what is a ‘ reference ’ or ‘ known good ’ value . Presumably , an Owner entity did some due diligence to ensure the KGV is indeed ‘ good ’ given Owners may not have access to source code or other tools that the original vendor has access to . But ultimately , all appraisal decisions are qualified by the Owner ’s wishes . There is complexity in ecosystems when a vendor ( e.g.  vendor ) does n’t give up ownership of the FW even though the computer is sold to the customer . The PC owner might have a policy that allows the BIOS vendor to supply an  policy for just the BIOS . The Roles architecture for the BIOS component may differ from the Roles architecture for other components . In this case , the Endorsement and  roles may be supplied by the same Entity ( i.e. the bios vendor ) . See more inline below - Nms 
 The architecture doc should ( must ? ) facilitate a good understanding of attestation end - end for the reader . K - g - v seem like a very core concept to attestation . Leaving them out of the architecture document will leave the reader scratching their head , like I was scratching mine . I do n’t think it has to be a detailed , concise or definitional explanation . Something like this : For some claims the Verifier will compare the claims in the Evidence to known - good - values or reference values . In many cases these are hashes of files , SW or memory regions . In other cases they might be expected SW or HW versions . In other cases , they may be something else . The actual data format and semantics of a known - good - value are specific to claims and implementations . There is no general purpose format for them or general means for comparison defined in this architecture document . These known - good - values may be conveyed to the Verifier as part of an Endorsement or as part of   or both as these are the two input paths to the Verifier . LL 
 I agree that the concept Laurence outlines should be in the architecture doc . I think there are words to that effect currently . For example , section 7.2 says “ devices from a given manufacturer have information matching a set of known - good reference values , ” and “ Thus , an Endorsement may be helpful information in authenticating information about a device , but is not necessarily sufficient to authorize access to resources which may need device - specific information such as a public key for the device ” Admittedly , this is scant and leaves a lot to the reader to figure out or make assumption . The architecture could more clearly capture the idea that Endorsements are “ reference ” claims that are compared with Evidence claims to validate their correctness . It should introduce other common terms such as ‘ known good values ’ , ‘ reference values ’ and ‘ endorsed values ’ as roughly synonymous . I think it should go further to say that Endorsements can include values that are static ( intrinsic ) that do n’t require attestation , but can be asserted about a class of device , platform , entity and appraised according to an appraisal policy for Evidence ( Even though the claims do n’t appear in Evidence ) . While I think it is possible to interpret the existing wording according to the above understanding , it is also possible to interpret it differently . Therefore , the section should be improved . I also think the first sentence ( and definition in terminology ) are insufficient . While “ An Endorsement is a secure statement that some entity ( e.g. , a manufacturer ) vouches for the integrity of the device ’s signing capability . ” – is correct , it is insufficient because it is also a statement about the devices Attesting Environment ability to collect claims securely . 
 Given that this Architecture document will serve as a guide to additional work that is needed from RATS wg to define data schema , interfaces for an interoperable implementations of verifiers with endorsements from multiple vendors to be compared with evidence from different implementation of attesters , is n't it worthwhile creating a hook in this document for scope of work needed to tackle it in future documents ? If yes this document should define KGV , the types of KGVs that can be endorsed or defined in attestation policy , a need for data schema for each type of KGV and a set of interfaces to fetch / publish it deferred to a future document . Similar to claims encoding formats specified in section 8 , a specification needed but deferred to future document for KGV endorsement formats would be useful . 
 A google search for " known good values " yields some mention in the Cisco trust center and a few books on security .   mentions " good measurements " once that I could find . So there 's some use of the term out there and it seems worth mentioning along with RIM . It is also a very descriptive term that is probably immediately clear to the user .
Paragraph (version B):
For example, for some claims the Verifier might check the values of
claims in the Evidence against constraints specified in the Appraisal
Policy for Evidence.  Such constraints might involve a comparison for
equality against reference values, or a check for being in a range
bounded by reference values, or membership in a set of reference
values, or a check against values in other claims, or any other test.
Paragraph (version B):
Such reference values might be specified as part of the Appraisal
Policy for Evidence itself, or might be obtained from a separate
source, such as an Endorsement, and then used by the Appraisal Policy
for Evidence.  The actual data format and semantics of a known-good
value are specific to claims and implementations.  There is no
general purpose format for them or general means for comparison
defined in this architecture document.  Similarly, for some claims
the Verifier might check the values of claims in the Evidence for
membership in a set, or against a range of values, or against known-
bad values such as an expiration time.  These reference values may be
conveyed to the Verifier as part of an Endorsement or as part of
Appraisal Policy or both as these are the two input paths to the
Verifier.