Re: [Rats] New Version Notification for draft-lundblade-rats-eat-media-type-00.txt

Anders Rundgren <> Tue, 19 July 2022 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52B35C14F737 for <>; Mon, 18 Jul 2022 20:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wG-okNxUC1Mn for <>; Mon, 18 Jul 2022 20:35:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 4E984C157B47 for <>; Mon, 18 Jul 2022 20:35:15 -0700 (PDT)
Received: by with SMTP id h17so19779696wrx.0 for <>; Mon, 18 Jul 2022 20:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=sLVkzNjTDabMUwWHIGIUe8t78w8T1Mjea5Tl0Yzz1Q4=; b=UvRlmZT8/KI1aOfd7pte911zmlEqdqXObt+zf0vBOgQ3yq5/d9i0JH8fWf/2LDxe0R EWYaFtCyoGdd+oUGap7Z4Xiq1ZMC+kk87UPbtobkxwFZgk4KirsElM4feZHgrKdgyb78 cEPiRE2QAofS5LaVz0zn01iYh/VCv6eqrHnbeNWaX3qeOBp6FzGB+uPvz1lsx6e9rx33 2Jc9vWXP8i3I6E4NfNKDqSRG1T4ZJ+szZIAKw3vVPicXkjc7yBjMNdDjbFA3wf2UJwQ7 X7i/0ocAUT2YjyXCAKvgK157XNy0ndtuQBqAiizeKmLR95FgIjDBn8ZfbEBqRvdkJm4D DHUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=sLVkzNjTDabMUwWHIGIUe8t78w8T1Mjea5Tl0Yzz1Q4=; b=CsP4fTM32z85pvcTgLlG+baE+mFpJvNSeHChTbPKEYvJFPtph/12zskBZ6eUNkaX4t 4KUo7Zz7Sci9PIqTOf84JPRjm1tRq89/ZmfIa7DGehW1nunC2qr4d8Uzazdij4hoTJ5G 34wmgY75J1zVBQRPUc/eLMva98J/kGcI023TSPU4vVXYYWsm3Zqd2KIpCJIym9Tkov4U /judph2uDdjp3+pEfApDPQzA/H8jHwElOd7lcvojSIPtob/0jon1irnJJ8im7VBfxaO+ LuFXPiy2Xqk8ORKtPv21ojMosksNTbiQjgUDFDdSDbyTYJRht3bZI+ZGuU0P2FFLGCI0 YJ/g==
X-Gm-Message-State: AJIora8aySYmWIIS5BMdKENFJqXRGrC6RCxZBntsG092cNAeOxyqVpp9 W+siLXVPHSuDPZgqV/xDvr0ZqAbueOc=
X-Google-Smtp-Source: AGRyM1uG6grE/bJl11sZjQBKmxDLRP2ZGi+MitK5oA1YjrRdN1xHiKa5ZxltoXFOQ7wT92HCVeSd/g==
X-Received: by 2002:adf:dd52:0:b0:21d:941a:3ade with SMTP id u18-20020adfdd52000000b0021d941a3ademr24966621wrm.10.1658201713380; Mon, 18 Jul 2022 20:35:13 -0700 (PDT)
Received: from ?IPV6:2a01:e34:ec4e:5670:4905:c6a3:607e:5f01? ([2a01:e34:ec4e:5670:4905:c6a3:607e:5f01]) by with ESMTPSA id h13-20020a5d6e0d000000b0021b9e360523sm12042456wrz.8.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 20:35:12 -0700 (PDT)
Message-ID: <>
Date: Tue, 19 Jul 2022 05:35:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Dave Thaler <>, "Birkholz, Henk" <>, Laurence Lundblade <>, Thomas Fossati <>
Cc: "" <>
References: <> <> <>
From: Anders Rundgren <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Rats] New Version Notification for draft-lundblade-rats-eat-media-type-00.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jul 2022 03:35:19 -0000

On 2022-07-18 21:38, Dave Thaler wrote:
> Thanks for submitting this draft.  I think the WG should adopt it as a WG document.

Hi Guys, feel free to adopt this as a WG document but you may read the following first.

There are reasons for using media types for providing additional type information.  However, there are also reasons for not taking this path which have not been discussed in any detail.

My main objection to this draft is that it departs from current best(?) practices:

1. There are gazillions of REST-based services out there using a single and non-parameterized mime-type (application/json).

2. FIDO attestations are already self-contained making them transferable over different transports as well as straightforward storing in databases or embedding in other objects.
     "fmt": "apple",
     "attStmt": ...

     "fmt": "tpm",
     "attStmt": ...

A "proper" solution should therefore (IMO...)
- be self-contained
- use a single mime type
- if signed, include the entire object (modulo the signature value itself) in the signature calculation

If there is a need figuring out the type of an object, before reading the rest, the way FIDO does this seems good enough.  As you may have noted, I have suggested a CBOR tag [*]
    211TBD([object type-id, object data])
intended to address this issue for a wide range of applications.  I would love to realize this as an RFC within the RATS or CBOR WG.


  *] This can be tried out at:
The current implementation requires type-id to be a "string" and data to be a map {}.

> I have reviewed it, and used it in the latest draft-ietf-teep-protocol draft (which during the last RATS meeting I said I would do).
> I have just one wording suggestion.  In section 3 it says:
>> The media types defined in this document include an optional profile
>> parameter that can be used to mirror the eat_profile claim of the
>> transported EAT.  Exposing the EAT profile at the API layer allows
>> API routers to dispatch payloads directly to the profile-specific
>> processor without having to snoop into the request bodies. 
> That is of course true, but the justification can be even stronger by pointing out that it also allows use when the payload is not present in the message, such as in an Accept header (and indeed section 4 shows that).
> Indeed, the TEEP protocol uses it in both Content-Type and Accept, just like in section 4.
> Dave
> _______________________________________________
> RATS mailing list