Re: [Teep] Security domain default 1-to-1 mapping to a TA proposal in TEEP

[Andrew Atyeo <[e-mail]>]

Hi,
I have updated the github issue with my comments
https://github.com/ietf-teep/architecture/issues/7

basically I understand that there are some deployment types that might prefer a simpler approach, but I want to make sure that we know what would be ‘lost’ by not having a SD that is created separately. It might be that for some deployments the loss is no problem, or it might be that there could be alternative ways to give the same functionality but without need for a separate createSD that are worth exploring.
The github issue (link above) hopefully explains this better.

Regards,

Andrew Atyeo
Security Architect
Intercede
Digital trust    people ǀ devices ǀ apps
Office: [phone]
www.intercede.com<https://www.intercede.com/>
Legal Disclaimer <https://www.intercede.com/privacy-cookies>
From: Mingliang Pei <[e-mail]>
Sent: 08 March 2019 02:00
To: Andrew Atyeo <[e-mail]>
Cc: [e-mail]
Subject: Security domain default 1-to-1 mapping to a TA proposal in TEEP

Hi Andy,

We are working on to close this issue #7: clarifying meaning of Security Domain (SD)

https://github.com/ietf-teep/architecture/issues/7

We want to simplify it, and propose to create a SD per TA by default, without completely removing the SD for some existing use cases. It will be good to also have your input on the implications, considering you have more involved in this with a prior OTrP TAM POC implementation. Could you review the issue, and provide comments there?

Here is a quick recap on some discussion reasonings.

Historically we consider Security Domain as a first class entity in TEEP (OTrP). There have been some desires to simplify it, or not require it in the TEEP architecture as some use cases don’t use it as much as potential IoT use cases. On the other hand, we know that existing TEE implementations and other secure element related practices uses SD to isolate and associate protection boundary. There was some resource constraints on number of SDs that can be allocated in a TEE device.

To achieve broad support of both worlds, we consider to move to an “implicit” model as follows:


  *   One SD is created per TA when a TA is going to installed. This allows creation of TA without going through explicit SD creation and so on.
  *   The prior deletion of SD will delete all TAs within the same SD. Now each TA will be required to be explicitly deleted.

Thanks,

Ming