Attendees
Abhishek Pandit (Arm)
Christian Daudt (Cypress)
Dan Handley (Arm)
David Brown (Linaro)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Eric Finco (ST)
Mark Grosen (TI)
Bill Mills (TI)
Bill Fletcher (Linaro Community Projects)
Agenda
CNA training
Provisioning
ELC TF-M workshop in Lyon
Git process flow
OP-TEE git update
Notes
DB: CNA training? CVE Numbering Authorities. Able to assign CVEs in blocks
of 10 without going through a minder. No charge. Same amount of time as we
should be spending on CVEs anyway.
JB/DH: Think it’s a good idea.
DH: Would like to establish who is on the security mailing lists.
JB: Have had bad experience working through Mitre.
CD: To clarify this the scope is TF-A, TF-M, OP-TEE
DB: Yes.
CD: Not much purpose to get CVEs if we don’t have anyone to do anything on
them.
DB: CF Zephyr …
DH: Will send email to allow people to formally sign off on this
DB: I would like to have a discussion about provisioning. Right now, it
seems that the only way we specify a device identifying itself is by giving
its public key, which would require that every device to be provisioned be
entered into some kind of database before it could be known. Instead I'd
like to propose that we have a way of storing and retrieving an X.509
certificate, which would have that public key in it, along with a signature
chain that could be used to indicate that this device is trusted. This is
commonly done in deployed devices, and we might as well add this
functionality now.
AP: Had proposed a provisioning-specific slot, but no one registered
interest. Will still schedule this.
DB: Have defined attestation token signed with a private key internal to
device. There is also a public key. If only this, it has to be known by the
entity on the other side to know a valid device. Preferred approach is a
certificate - that public key signed by an authority.
https://github.com/microbuilder/zephyr/blob/tfm-psa-level-1/samples/tfm_int…
Need to “get a certificate” … is this a trusted device?
DB: Different to e.g. MQTT using a TLS certificate. Need to be flexible
allowing a public key registration.
KT: How to know if a device should be joining the network with just public
key.
DB: Unless a channel from the factory with a list of trusted devices.
DB: May also need a mechanism to update these keys
BM: Overlap with Intel?
JB: Yes. Pelion was the collaboration between Intel and Arm
BM: Think the base concept was simpler.
JB: Talk to Reed Hinkel about the LEDGE presentation session on this.
EF: Got it through the mailing list of LEDGE.
AP: Would like to do this as a provisioning subgroup and then ask the TSC
if they want to proceed. Happy for David or Kevin to lead the discussion.
CD: Shall we see if can have a similar discussion to the one we had at
Connect
JB: Can ask Francois or Reed to see if they can help us.
AP: If you know someone who is interested, we should extend to wider than
TSC. Will schedule the meeting.
MG:
https://www.intel.com/content/dam/www/public/us/en/documents/idz/iot/briefs…
AP: TF-M workshop in Lyon after ELC. Will discuss the outcomes at next TSC.
MG: Git flow. How to know when it’s a good time to integrate with the TF-M
workflow. Aren’t many tags etc. Have tried with some issues. Are there
engineering builds, alpha builds?
AP: Can take guidance as TF-A which is more mature. Need to decide if 6
monthly test cycle as TF-A. Need solid branches to base work on. Dual core
work ongoing on a branch. Posted requests for review but there were no
reviews. Has been no drive to fix the methodology yet.
AP: CI running but it’s problematic with MPS2 at the moment.
CD: But no formal cycles yet
AP: Arm stretched to support the feature requests at the moment. Will talk
to Shebu to structure the roadmap in order to have something stable.
JB: Forked OP-TEE gits are now at git.trustedfirmware.org
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
I would like to have a discussion about provisioning. Right now, it seems
that the only way we specify a device identifying itself is by giving its
public key, which would require that every device to be provisioned be
entered into some kind of database before it could be known.
Instead I'd like to propose that we have a way of storing and retrieving an
X.509 certificate, which would have that public key in it, along with a
signature chain that could be used to indicate that this device is trusted.
This is commonly done in deployed devices, and we might as well add this
functionality now.
David
On Tue, Oct 8, 2019 at 5:00 PM Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Any agenda items for the meeting this week?
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
