Re: [Rats] Dealing with Attestation Roots

[Laurence Lundblade <[e-mail]>]

> On Apr 23, 2020, at 8:31 PM, Anders Rundgren <[e-mail]> wrote:
> 
> 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.

Android uses X.509 both for the attestation token and to chain up from a root to a verification key. Agreed that the X.509 for the attestation token is not preferred as a standard. I wasn’t suggesting that. I was suggesting that X.509 is used WITH CWT/EAT to chain up from a root to a verification key per https://tools.ietf.org/html/draft-ietf-cose-x509-06 <https://tools.ietf.org/html/draft-ietf-cose-x509-06>. I think I’m agreeing with you.

> 
> 
>> 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.

Yes, I generally I agree with you on all this.

Though I think there are other ways than an X.509 root certificate and a URL for it to find a verification key. 

I think we should have an IETF RATS draft that says how to use X.509 roots and hierarchies plus a URI with EAT/CWT.

LL



> 
> 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 <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 <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]> <mailto:[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]> <mailto:[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
>>> 
>>> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>