[Rats] Re: I-D Action: draft-ietf-rats-ear-04.txt

[Henk Birkholz <[e-mail]>]

On 10.06.26 13:35, Thomas Fossati wrote:
> Hi Henk,
> 
> On Wed, 10 Jun 2026 at 12:38, Henk Birkholz <[e-mail]> wrote:
>> so... the Verifier could take on that burden?
> 
> That would amount to saying that the verifier:
> 1. MUST support all two/three encoding variants, and
> 2. MUST expose an API that allows the client to select which variant to use.

This is like saying "it MUST support all types of evidence 
transformations" which is obviously not the intend, right? Some Relying 
Parties will support the default conveyance via COSE_Key, some will 
require a Verifier to do it for them.

> 
> Very few verifiers, if any, will accept that burden.  There is simply
> too much complexity to maintain.
> Bear in mind that the three variants are not exactly isomorphic, and
> there are subtle differences between any two of them that would result
> in information being lost when switching between formats.
> 
>> We have not specified a
>> lot about the Relying Party influencing the form and shape of Evidence
>> and ultimately the Attestation Result. As a Verifier already is burdened
>> with Evidence transformation (e.g.,
>> https://datatracker.ietf.org/doc/draft-ietf-rats-evidence-trans/) it
>> seems to me that it is also its duty to exhibit some "Relying Party
>> empathy" and transform key material into a representation appropriate
>> for the Relying Party.
> 
> IIUC, the idea is that since the verifier already handles many
> complicated tasks, adding one more wouldn't be a problem.
> This is not a particularly compelling argument, isn't it?
> 
> cheers, t
> 
> 
>> EAR is about Attestation Result content. If you go with just one "key
>> representation" allowed in Attestation Results, some Relying Parties
>> will always get some transformation burden assigned (and by excluding
>> the COSE variant which is common in IoT, it mabye is the IoT devices
>> that might carry the largest part of that burden).
>>
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 10.06.26 12:25, Ionut Mihalcea wrote:
>>> Hi Henk and all,
>>>
>>> In the long term I agree that transformation is inevitable, but given
>>> the current ecosystem, Lindy's law, and the need to get designs and
>>> software out, we need to support something akin to SPKI anyway. And dual
>>> support (COSE_Key + SPKI) is not a burden for a Verifier, but (in my
>>> view at least) relying parties are meant to be the least-RATS-savvy
>>> entities, so any complexity or divergence would best be consumed by the
>>> other participants instead.
>>>
>>> I'd lean towards simplicity and vote for SPKI only.
>>>
>>> Cheers,
>>> Ionut
>>>
>>> *From: *Henk Birkholz <[e-mail]>
>>> *Date: *Wednesday, 10 June 2026 at 11:01
>>> *To: *Michael Richardson <[e-mail]>; Thomas Fossati
>>> <[e-mail]>; [e-mail] <[e-mail]>
>>> *Subject: *[Rats] Re: I-D Action: draft-ietf-rats-ear-04.txt
>>>
>>> THB, a COSE_Key (and if the symmetry is required JWK) as a single source
>>> of truth to derive from does not seem overly burdensome to me.
>>> Transformation will be inevitable in any case.
>>>
>>> On 09.06.26 16:47, Michael Richardson wrote:
>>>   >
>>>   > Thomas Fossati <[e-mail]> wrote:
>>>   >      >> It's also, as I recall, the format for DNSSEC DNSKEY RR
>>> (isn't it? I
>>>   >      >> could check)
>>>   >
>>>   >      > It doesn't look like SPKI to me:
>>>   >
>>>   >      > $ dig DNSKEY ietf.org +short 256 3 13
>>>   >      > oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWzJaOau8XNEZeqCYKD5ar0IRd8
>>>   >      > KqXXFJkqmVfRvMGPmM1x8fGAa2XhSA== 257 3 13
>>>   >      > mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+
>>>   >      > KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
>>>   >
>>>   > Yes, RFC3110 defines the RSA DNSKEY (and KEY), which is not SPKI.
>>>   > And RFC4025 uses KEY format.  And RFC9373 says RFC8080 describes
>>> EdDSA, which
>>>   > is also not SPKI.
>>>   > I seemed to pattern match (Hallucinate!) that we used the SPKI object
>>>   > somewhere way outside of any ASN.1 attached protocol... in something
>>> major.
>>>   >
>>>   > Why does this matter?  because libraries that load it, without
>>> bringing in a
>>>   > full DER parser.
>>>   >
>>>   > --
>>>   > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
>>> consulting )
>>>   >             Sandelman Software Works Inc, Ottawa and Worldwide
>>>   >
>>>   > **       My working hours and your working hours may be
>>> different.         **
>>>   > ** Please do not feel obligated to reply outside your normal working
>>> hours **
>>>   >
>>>   >
>>>   >
>>>   >
>>>   >
>>>   > _______________________________________________
>>>   > RATS mailing list -- [e-mail]
>>>   > To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> RATS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> RATS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]