Re: [Rats] Dealing with Attestation Roots

[Anders Rundgren <[e-mail]>]

On 2020-04-23 21:20, Laurence Lundblade wrote:
> Hi Anders,
> 
Hi Laurence;

> I think using an X.509 hierarchy with EAT is a fine thing to do, but no one’s done it yet. 

I see it more like a workaround in the absence of a standard.  Using CWTs is a better solution.


The two EAT implementations I know of, use other means to find the verification key. One by key ID, another by a combination of claims inside the attestation.

Somewhere there must be a trust anchor or a trusted public key, right? How do you locate it expressed in practical terms?  This is the only thing the "Web PKI + Vendor URL" proposal was meant to addresses.  For those who have doubts about automated retrieval of trust anchors based on vendor-specific host names, the scheme can also aid manual installation of such.

The proposal is neutral with respect to key hierarchy.  A flat or multi-level (as in Android) scheme would be dealt with in the same way.

Anders

> 
> Android’s solution is not standard, it is just used by Android AFAIK.
> 
> I think it would be fine to write a draft that says how to use X.509 with EAT. It would involve https://tools.ietf.org/html/draft-ietf-cose-x509-06 and maybe the URL you’ve suggested for finding the root. Would even be interested in adding this functionality to ctoken <https://github.com/laurencelundblade/ctoken>.
> 
> Technically speaking, this is all about endorsements and relates to recent email threads on that subject here.
> 
> LL
> 
> 
>> On Apr 22, 2020, at 7:54 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> On 2020-04-22 16:38, Laurence Lundblade wrote:
>>> Hi Anders,
>>
>> Hi Laurence,
>> Thank you for responding!
>>
>>>> On Feb 27, 2020, at 9:51 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>> Hi List,
>>>> In the https://cyberphone.github.io/openbankingwallet project the idea was to use attestations.  The most recent version of the Android app indeed supports this as well.
>>>>
>>>> In an ideal world the root would be provided by Google.  However, since we don't live in an ideal world there are vendors out there who do not follow that "recipe”.
>>> Are you referring to Android N Key Attestation that is implemented in the key store?
>>
>> This is indeed one possible usage.
>> https://developer.android.com/training/articles/security-key-attestation
>>
>>>>
>>>> For W3C's PaymentRequest API a simpler solution is used which do not match attestations but is better than nothing.  This scheme builds on publishing a manifest associated with the app.  Here is my particular manifest:  https://mobilepki.org/w3cpay/method
>>>>
>>>> But I still would like to use attestations and also not being tied to browsers.
>>>>
>>>> What about making attestations optionally contain a URL to the root like https://huawei.com/teeroot ?
>>> I don’t know what https://huawei.com/teeroot  is. I can’t get anything from this URL.
>>
>> That's correct, I don't even know where to find Huawei's attestation root which is how I came to this idea :)
>>
>>
>>> I’m guessing you are after an X.509 root certificate, one that is used for Android-style attestation. Is that right?
>>
>> Right.  Is using an X.509 root certificate an unusual way of dealing with attestation verification?
>>
>> Anders
>>
>>> LL
>>>> Since the number of vendors in finite and the Web-PKI is in a fairly good shape these days, this could serve as a workaround for those who don't have any number of cycles to spend on installing arbitrary tee root certificates.  That is, a verifier's "trust registry" would simply hold host names like "huawei.com", "sony.com", "samsung.com", etc.
>>>>
>>>> If there is a better method, I'm all ears!
>>>>
>>>> thanx,
>>>> Anders
>>>>
>>>> _______________________________________________
>>>> RATS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
>