]> Sandelman Software Works

mcr+ietf@sandelman.ca

Security RATS (if adopted) geofence workload soverign computing Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. This document is about encoding a variety of geographical conclusions in an Attestation Result. About This Document Status information for this document may be found at . Discussion of this document takes place on the RATS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Resolving the question of where certain computations occurs can be critical to assessing how much trust to put into the result. Example. Example. Example. provides a framework that allows an Verifier to return a conclusion as to geographic region for an Target Environment. While provides a very good WGS84 based location claim, often very suitable as Evidence, it is not ideal for the use by Relying Parties. There are a few reasons:

• the latitude and longitude describe a location on the Earth. The Relying Party is seldom interested in that level of detail. It needs to know if it's in the correct place.
• the geographic position leaks significant amount of private information that is not necessary for the Relying Party to know.
• for many activities, it is the Legal Jurisdiction that matters, not the actual location. Jurisdictions often do not have well defined concentric boundaries. For instance, the Korean Consultate in Los Angelos is usually for Legal purposes, in Korea. Yet, only a few meters away, possibly below the level of WGS84 accuracy, the jurisdiction would be different.

This document offers a new set of structured abstract claims that provides an evaluated view of where a Target Environment is. The mechanism to do this appraisal may depend upon a number of factors which may be related to physical geographic position, but also include other considerations. For instance, a claim that Target Environment is less than 1ns (as light travels in a fiber optic cable) away from another Target Enviroment whose location is known. A typical fiber optic cable has a speed of 200,000 kilometers per second (slower than light in a vacuum to the index of refraction of the glass involved. So if the round trip time between environments is 1ns, then the distance between Target Environments can be appraised to be within 1m of each other.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Claim definition This claim definition goes into the EAR submods map. Mumble mumble. AR4SI + $ear CDDL TBD. Geographic Results can contain one or more of the following claims.

1. jurisdiction-country = ISO3361 country code.
2. jurisdiction-country-exclave = booleann
3. jurisdiction-state = country-specific list
4. jurisdiction-state-exclave = country-specific-list
5. jurisdiction-city = state-specific list
6. jurisdiction-city-exclave = state-specific-list
7. enclosing-exclave-country = ISO3361 country code
8. near-to = another entity+distance
9. rack-U-number = ordinal, numbered from bottom RU as 1.
10. cabinet-number = ordinal, DC specific ordering, might ignore hallway, room and floor
11. hallway-number = ordinal
12. room-numbr = string
13. floor-number = string, usually representing an integer.

There are some additional things which may be received as Evidence, but which is sometimes important to convert to Results, having verified some aspects. (TBD) 1. range-to-tower = designation of tower, distance-readings 2. (NOTE: There are apparently exclaves that ar inside other countries exclaves, like Nahwa. Unclear if exclave information is even relevant, or if second order matters at all)

CDDL Definition geographic-result-claims ) geographic-result-claims = non-empty<{ ? grc.jurisdiction-country-label => iso-3361-alpha-2-country-code ? grc.jurisdiction-country-exclave-label => bool ? grc.jurisdiction-state-label => tstr .size (2..16) ? grc.jurisdiction-state-exclave-label => bool ? grc.jurisdiction-city-label => tstr .size(2..16) ? grc.jurisdiction-city-exclave-label => bool ? grc.enclosing-exclave-country-label => iso-3361-alpha-2-country-code ? grc.near-to-label => corim.uuid-type ? grc.rack-U-number-label => uint .gt 0 ? grc.cabinet-number => uint .gt 0 ? grc.hallway-number => uint ? grc.room-number => tstr .size (2..64) ? grc.floor-number => int }> ear.geographic-result-label = eat.JC<"TBD02", TBD01> grc.jurisdiction-country-label = eat.JC<"grc.jurisdiction-country", 0> grc.jurisdiction-country-exclave-label = eat.JC<"grc.jurisdiction-country-exclave", 1> grc.jurisdiction-state-label = eat.JC<"grc.jurisdiction-state", 2> grc.jurisdiction-state-exclave-label = eat.JC<"grc.jurisdiction-state-exclave", 3> grc.jurisdiction-city-label = eat.JC<"grc.jurisdiction-city", 4> grc.jurisdiction-city-exclave-label = eat.JC<"grc.jurisdiction-city-exclave", 5> grc.enclosing-exclave-country-label = eat.JC<"grc.enclosing-exclave-country", 6> grc.near-to-label = eat.JC<"grc.near-to", 7> grc.rack-U-number-label = eat.JC<"grc.rack-U-number", 8> grc.cabinet-number = eat.JC<"grc.cabinet-number", 9> grc.hallway-number = eat.JC<"grc.hallway-number", 10> grc.room-number = eat.JC<"grc.room-number", 10> grc.floor-number = eat.JC<"grc.floor-number", 11> iso-3361-alpha-2-country-code = tstr .size 2 ]]>

Security Considerations TODO Security

IANA Considerations IANA is asked to allocate TBD01 from the "CBOR Web Token Claims" registry , and TBD02 (suggestion: "ear.geographic-result-claims") from the "JSON Web Token Claims" registry .

References Normative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IANA IANA Genuine Modules Wikipedia

Acknowledgments TODO acknowledge.