Re: [Rats] Attestation key material in architecture document

Thanks for updating the issue. I will attend the architecture meeting when it is discussed. :-)

A good first step would be to determine if there is consensus that the 7 cases I described (TRUST_ANCHOR…VERIFICATION_SERVICE) should be allowed and supported by RATS. There were no fundamental objections in the 108 RATS meeting, but it would be good to know explicitly there is consensus on this so we’re working from a common base.

Does anyone think RATS architecture should explicitly exclude any of these 7?

LL

> On Jul 30, 2020, at 3:31 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
> 
> Hi Laurence,
> 
> I updated issue #65 for you:
> 
>> https://github.com/ietf-rats-wg/architecture/issues/65 <https://github.com/ietf-rats-wg/architecture/issues/65>
> 
> This will make it easier for the editors to address your two alternative proposals. I think it would help, if you are present when we discuss this.
> 
> MCR: do we plan for an editor's meeting next Tue?
> 
> Viele Grüße,
> 
> Henk
> 
> On 29.07.20 22:14, Laurence Lundblade wrote:
>> I presented this slide below the IETF 108 RATS meeting today. I believe it is critical that the RATS architecture allow for all uses case in the slide.
>> In particular RATS architecture must allow for symmetric keys. TPMs and public-key based crypto is too expensive for low-cost, large-scale IoT. There are real use cases supported my multiple companies using symmetric keys. Symmetric keys can be made secure at the verifier — we secure keys for TLS at servers all the time using HSMs and such.
>> I do NOT want to put this taxonomy into the RATS architecture document. I don’t think that is necessary. I created the taxonomy as background information and as illustrative examples of real world designs.
>> I think there are options for adjusting the architecture document to accommodate this.
>>    Option 1) Expand the notion of an Endorsement quite a lot.
>>    Endorsements are not longer just static documents like X.509 certs
>>    and/or COSE/CMS signed blobs. They are anything that conveys the
>>    attestation key material into the Verifier or allows Verification of
>>    the attester. They must support confidentiality.
>>    Option 2) Replace the term “Endorsement” with something like
>>    “Verifier Input” or “Attester Trust Criteria” in the architecture
>>    document as the means by which key material goes into the Verifier.
>>    Endorsements still exist, but are just one type of Verifier Input or
>>    Attester Trust Criteria just like EAT is one kind of Attestation
>>    Evidence.
>> I have a slight preference for Option 2). I’m interested in opinions of which option to choose.
>> This is issue #65 <https://github.com/ietf-rats-wg/architecture/issues/65 <https://github.com/ietf-rats-wg/architecture/issues/65>>, opened in GitHub four months ago. It is not a last-minute/new issue. I believe it is in scope with the RATS charter as the charter explicitly mentions attestation key material in the Program of Work.
>> LL
>> My main point of this taxonomy was to affect the RATS architecture document. There was discussion today of it being a separate document perhaps outside of RATS. I’m happy for that to happen, but I don’t want to write it because I have enough RATS/EAT work to do. I’m very happy if other folks want to pick it up and use in other documents :-).
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>