Re: [Teep] [Rats] EAT claims needed by TEEP

There has been some detailed discussion on the PR [1] but I'd like to
point out a couple of more high level considerations.

Using a byte string (i.e., with no explicit typing) means coupling all
the RATS roles around the *syntax* of the claim.  For example, a
reference value provider (maybe a third party rather than the ODM
itself) would need to have detailed knowledge of the specific encoding
used by the attester on a given device in order to correctly instruct
the verifier.  While this is likely OK for a bunch of very simple
cases, I don't think it's a viable strategy in general.

An OID could be in dotted-decimal notation or BER-encoded or
RFC9090-encoded, an URI could be a string or a CRI, UUIDs could be in
canonical 8-4-4-4-12 format or binary encoded, etc.  All of those
encodings should be possible as long as it's understood by all the
involved roles that the thing is a URI or whatever.  The roles
distinction in the RATS architecture requires shared semantics, not
shared syntax.  In fact, I don't think we can have fine-grained
appraisal policies without a well defined typing system as the base for
the semantic layer.

Besides, it looks like we'd be creating a bad precedent because then one
could easily argue that *every* claim is possibly just a byte string or,
pushing this line of reasoning just a bit further, the whole claims-set
could be seen as one single gigantic opaque claim.

That said, if TEEP wants to go down this road I think it's fair and
fine, as long as it remains within the TEEP scope (i.e., within the
confines of TEEP's EAT profile) and doesn't claim general applicability.

cheers, thanks!

[1] https://github.com/ietf-rats-wg/eat/pull/139/files

On Wed, Nov 10, 2021 at 10:09 PM Dave Thaler
<dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>
> Good point, I agree.
>
>
>
> Dave
>
>
>
> From: Laurence Lundblade <lgl@island-resort.com>
> Sent: Wednesday, November 10, 2021 1:26 PM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; rats@ietf.org; teep <teep@ietf.org>
> Subject: Re: [Rats] EAT claims needed by TEEP
>
>
>
> An advantage of a string over a UUID is that it can be very short if that’s all the OEM needs, “S”, “3, “X” and “Y” in the case of Tesla.
>
>
>
> LL
>
>
>
> On Nov 10, 2021, at 1:03 PM, Dave Thaler <dthaler@microsoft.com> wrote:
>
>
>
> If it's a string, I think it should be up to the vendor specified by the oemid,
> rather than by a vendor-agnostic profile.
> If it's a UUID then that's not needed.
>
> Personally I would argue for treating it as opaque in either case
> and a verifier should only compare it for equality, rather than permitting
> semantic structure in it.   That's because I think some hardware implementation
> may fillvin values that can be used for multiple profiles.
>
> Dave
>
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Wednesday, November 10, 2021 12:23 PM
> To: Laurence Lundblade <lgl@island-resort.com>; rats@ietf.org; teep <teep@ietf.org>
> Subject: Re: [Rats] EAT claims needed by TEEP
>
>
> Laurence Lundblade <lgl@island-resort.com> wrote:
>
> Appreciate the comments.  Think it is important to keep this generic
> since it is going in EAT. TEEP can have specific ways it uses HW class,
> but don't think we should be referencing TEEP in EAT.
>
>
> Then I suggest that:
>
>     "There is no global scheme or format for this claim."
> ->
>     "The format for this scheme will need to be specified within profiles that
>      use it."
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0        |   ruby on rails    [
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats

-- 
Thomas