Chairs: Nancy Cam-Winget, Tiru Reddy
Notetakers: Hannes Tschofenig, Michael Jenkins
DaveT goes through the open issues at https://github.com/ietf-teep/architecture/issues
Changes have been merged. One open issue (#223; definition of "software update")
Ming and DaveT suggested not to merge these changes into the draft.
Changes: Matching the title and the abstract. Intented status Standards Track. Document has also been submitted to the IESG.
Has a normative reference to the TEEP protocol.
Akira went through his slides.
The hackathon project was to implement the SUIT manifest in TEEP protocol.
Challenge 1 - terminology mapping between TEEP and SUIT
Challenge 2 - dependency resolution when there are several (2) manifests. The issue is that the developer provides a URL to the binary to one server but the TAM would like to change the storage location. How does the TAM change the URL in a secure way?
Brendan asked a question about metadata? Is there a better way to do it given that there are two trust domains?
Akira: Easy answer is "no".
43 - Update response may have latency; TAM that use nonce may have to store them for some time.
129 - Wonky Query Requests may result in error response.
132 - Future ciphersuites without confidentiality must come with discussion of security consideration and applicability (why it's okay)
139 - Challenges and tokens (in response to a Query Request) will not be combined - but only one can appear (if any at all)
131 - Protocol should not constrain number of available freshness mechanisms; registry established and negotiation mechanism defined (based on ciphersuite negotiation)
No discussion on the above
DaveT goes through the list of issues identified during the hackathon.
Brendan suggests that we need a capability discovery (algorithms, commands and parameters). Maybe also reporting of component identifiers. It should be pretty easy.
Dave: What should the TAM do with it? The TAM could use the attestation information - so I do not need the capabilities.
Brendan and DaveT. discussion goes in here.
DaveT: I suggest to remove the suit-command bit. If someone cares then they will probably use the suit-report functionality.
Support from the group with DaveT's proposal.
146: DaveT. suggested to go for approach (B) and there was no objection.
149: OCSP - there is an option to query for the service but no description of how to report or supply it. Remove or describe? There is support for including OCSP.
Ben asked what the extensibility mechanism.
Ming suggested to make OCSP mandatory.
Russ suggested to design it similiar to TLS (i.e. OCSP stapling).
Chairs: Nancy Cam-Winget, Tiru Reddy
Notetakers: Hannes Tschofenig, Ming Pei
Nancy: Note well
149: we start where we left off yesterday.
Options: 1) Remove OCSP, 2) specify a negotiation mechanism
DavidT explained what he means by the negotiation mechanism.
Ben talks about the need for having a revocation mechanism.
Ming: In OCSP we send OCSP stappled data but we didn't negotiate the ciphersuites. This slide proposes new functionality for negotiation and discovery.
DT: Russ made the argument that OCSP stappling might be difficult for constrained node. He was arguing that there are more lightweight solutions.
148: DT goes forward on explaining the solution for OCSP and what OTrP said. Should we re-use the text from the OCSP spec?
Hannes asked about the interworking between X.509 certificates, COSE and OCSP. He was suggesting to use a firmware update mechanism instead.
Ming: Do we support revocation steps with long-lived certificates? The question is really how.
Ben: OCSP does not really make sense with COSE. You might just be using hard-coded keys and you might be updating keys with software updates. It is probably still worth to mention that there is a need for revocation.
DT: We have an issue in the arch. document about using the TEEP protocol for trust anchor management. There is nothing special about the content being configured. Ming mentioned that we should mention that there is a need for a revocation mechanism and it should not mention how.
Ben and Ming agree.
DT: There would be no negotation mechanism.
Ben: The text in 148 still uses the term certificates.
DT: We can steal text from somewhere else and talk about public key cryptography or so. We can figure out what the appropriate wording is.
David Brown (from Jabber): Thinking about revocation by update re MCUboot. The issue is that MCUboot is generally immutable, but maybe the CRL could be something that could be updated (or part of the application).
Daniel Migault (by jabber): I agree with this way of doing.
Brendan Moran (by jabber): Revocation by update. I suspect that revocation by update is better for constrained devices.
147: TEEP CBOR tag
Ben: You might sometimes want to add a tag to CBOR structures to give them some semantic. The use of these tags can be purely optional. You can write your protocol/application such that these tags are purely optional. When the extra context is missing, there may be a need to use these tags.
DT: Does the TEEP tag need extra value?
Ben: I don't think so.
Hannes: Do not think so either.
DT: We should better remove it unless someone comes up with a reason for why we need it.
Furthermore, we don't need to use the tagged version of COSE_Sign1.
BM: The COSE_Sign1 tag is only useful if you allow a COSE_Sign
If you need multiple signers then you need COSE_Sign.
DT: We could use COSE_Sign1. We could add flexiblility by adding a separate tag. Finally, we could use tagged COSE_Sign1.
Hannes argued for not having the flexibility.
DT: We remove the tag and use COSE_Sign1 directly.
Ben (on jabber): We have (IIRC) other extensibility knobs we can use if we really want multiple signatures in the future
150: IANA registration: what should the policy be?
Hannes argued for 'Specification Required'.
DT: We will pick something and see whether the group likes it.
The group does not have a lot of views.
Brendan goes through a set of examples.
BM explains the detached signature mode.
DT: page 14 - one manifest
Hannes: asked about the personalization data unique per instance
BM: This is not in the slides. The approach is through TLS client authentication data (via the use of the HTTPS).
DT: Raises the point of moving some parts of the SUIT manifest document out into extension documents. Dependicies would move out to extensions - nothing else shown in this example.
Using HSS-LMS signature with personalization data may increase the cost according to number of devices, which might be quite big. signing huge number might be troublesome to handle state? If so, using ES256 like this example in page 11 is better, right?
Hannes asked Akira whether the example covers the hackathon use cases presented earlier.
Akira says yes. There was the additional issue regarding the order of the payload in the TEEP message.
BM: Link to the example presented by Brendan:
Core idea: You have the manifest -- what happens exactly at the device.
This is different from an attestation report because attestation reports attributes about your system rather than how those were obtained.
DT: In the example could it not find the TA binary.
BM: Yes. We might need to adjust the example because in the previous example both manifest were delivered together.