Subject: Re: [Teep] Artart last call review of draft-ietf-teep-architecture-16

From: Mingliang Pei <[email-masked]>
Date: Wed, 6 Apr 2022 17:54:35 -0700

Thanks Russ for your comments. Thanks Hannes for the PR. I made a minor
comment on the PR. The changes look good overall.

Please see my comments inline about "trust anchor" and "app store".

Best,

Ming

On Mon, Mar 28, 2022 at 11:06 PM Hannes Tschofenig <
[email-masked]> wrote:

> Hi Russ,
>
> Thanks for the review.
>
> I have created a few PR based on your comments:
> https://github.com/ietf-teep/architecture/pull/234
>
> I have added a few remarks below (mainly agreeing with your observations).
>
> Ciao
> Hannes
>
>
> -----Original Message-----
> From: Russ Housley via Datatracker <[email-masked]>
> Sent: Tuesday, March 29, 2022 12:08 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Artart last call review of draft-ietf-teep-architecture-16
>
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned ARTART reviewer for this Internet-Draft.
>
> Document: draft-ietf-teep-architecture-16
> Reviewer: Russ Housley
> Review Date: 2022-03-28
> IETF LC End Date: 2022-04-07
> IESG Telechat date: unknown
>
> Summary: Almost Ready
>
> Major Concerns: None.
>
>
> Minor Concerns:
>
> Section 3.3 says:
>
>    Weak security in Internet of Things (IoT) devices has been posing
>    threats to critical infrastructure that relies upon such devices.
>
> I'm a bit confused by this opening sentence.  IoT devices usually depend
> upon an infrastructure.  This seems to be talking about an infrastructure
> that depends upon a collection of IoT devices.  I suggest a minor edits to
> help the reader understand that this sentence is not talking about network
> infrastructure.
>
> [Hannes] I have changed the sentence to improve the wording.
>
> Section 9.3 says that a compromised REE "might drop or delay messages".
> This discussion should be expanded to include the replay of messages.
>
> [Hannes] Agree.
>
> Section 9.4 says:
>
>    A root CA for TAM certificates might get compromised or its
>    certificate might expire, or a Trust Anchor other than a root CA
>    certificate may also expire or be compromised.
>
> I do not understand the difference between a Root CA and a Trust Anchor.
> These are usually used a synonyms.  Please explain the difference that in
> intended here.
>
> [Hannes] Good point. I removed part of the sentence.
>
>
[Ming] Trust Anchor definition says "The Trust Anchor may be a certificate
or it may be a raw public key.". When it is a certificate, it doesn't have
to be the root certificate. It could be an issuing CA while it isn't a
common practice. Do we limit it to a self-signed root CA? I am fine with
this, and update accordingly.

> Nits:
>
> Section 1 says:
>
>    ... The problems in the bullets above, on the
>    other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
>    that can install and enumerate TAs in a TEE-secured location and
>    where another domain-specific protocol standard (e.g., [GSMA],
>    [OTRP]) that meets the needs is not already in use.
>
> Recommend breaking this long sentence up into at least two sentences.
> There are two points.  First, the need for a protocol to address the items
> listed earlier.  Second, where an existing domain-specific protocol does
> not already exist, a new more general protocol is needed.
>
> [Hannes] Splitting the sentence improves readability.
>
> Section 4.4 says:
>
>    ... Implementations must support encryption of
>    such Personalization Data to preserve the confidentiality of
>    potentially sensitive data contained within it, and must support
>    integrity protection of the Personalization Data.
>
> Why not say that implementation must support mechanisms for the
> confidentiality and integrity protection of such Personalization Data?
> Also, it seems like draft-ietf-suit-firmware-encryption offers one
> mechanism for such protection.  Should it be referenced here?
>
> [Hannes] Agree that the sentence should be simplified. You are also right
> by saying that a solution is available. I am not sure we should reference
> the solution in this document or in the protocol spec.
>
> Section 4: Is an "App Store" a place where apps are stored, or is it a
> place where apps a purchased?  The term seems to be used both ways, and in
> one place, the document is very general by saying, "an app store or other
> app repository".  Elsewhere, the term "Trust Anchor Store" is clearly a
> place for storage of trust anchors.
>
> [Hannes] I am not entirely sure what do about this one. I hope for input
> from my co-authors.
>
>
[Ming] "app store" intends to mean "where apps are stored and can be
acquired (such as Apple App Store / Google Play)". "Trust Anchor Store"
means some storage within a device to keep a list of Trust Anchors. How
about add a definition of "App Store" that was depicted in the diagram
under Section "Entity Relations" to say the following?

App Store: a service provider where an Untrusted Application may be
downloaded.

> Section 9.7: Please consider changing the section title to be something
> like: "TEE Certificate Expiry and Renewal".  There is an earlier section
> that talks about expiration of Root CA certificates.
>
> [Hannes] Makes sense.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Apr 2022 15:31:25 -0400

Please see below.

> On Apr 6, 2022, at 8:54 PM, Mingliang Pei <mingliang.pei=[email-masked]> wrote:
> 
> Thanks Russ for your comments. Thanks Hannes for the PR. I made a minor comment on the PR. The changes look good overall.
> 
> On Mon, Mar 28, 2022 at 11:06 PM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Russ,
> 
> Thanks for the review.
> 
> https://github.com/ietf-teep/architecture/pull/234 <https://github.com/ietf-teep/architecture/pull/234>
> 
> From: Russ Housley via Datatracker <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> I'm a bit confused by this opening sentence.  IoT devices usually depend upon an infrastructure.  This seems to be talking about an infrastructure that depends upon a collection of IoT devices.  I suggest a minor edits to help the reader understand that this sentence is not talking about network infrastructure.
> 
> These are usually used a synonyms.  Please explain the difference that in intended here.
> 
> [Ming] Trust Anchor definition says "The Trust Anchor may be a certificate or it may be a raw public key.". When it is a certificate, it doesn't have to be the root certificate. It could be an issuing CA while it isn't a common practice. Do we limit it to a self-signed root CA? I am fine with this, and update accordingly.

I think the point about not a "Root Certificate" in all situations is very helpful.  Please add that to the document.

> There are two points.  First, the need for a protocol to address the items listed earlier.  Second, where an existing domain-specific protocol does not already exist, a new more general protocol is needed.
> 
> Why not say that implementation must support mechanisms for the confidentiality and integrity protection of such Personalization Data?
> Also, it seems like draft-ietf-suit-firmware-encryption offers one mechanism for such protection.  Should it be referenced here?
> 
> [Hannes] Agree that the sentence should be simplified. You are also right by saying that a solution is available. I am not sure we should reference the solution in this document or in the protocol spec.
> 
> Section 4: Is an "App Store" a place where apps are stored, or is it a place where apps a purchased?  The term seems to be used both ways, and in one place, the document is very general by saying, "an app store or other app repository".  Elsewhere, the term "Trust Anchor Store" is clearly a place for storage of trust anchors.
> 
> [Hannes] I am not entirely sure what do about this one. I hope for input from my co-authors.
> 
> 
> [Ming] "app store" intends to mean "where apps are stored and can be acquired (such as Apple App Store / Google Play)". "Trust Anchor Store" means some storage within a device to keep a list of Trust Anchors. How about add a definition of "App Store" that was depicted in the diagram under Section "Entity Relations" to say the following?

Definitions would resolve this comment.

> 
> App Store: a service provider where an Untrusted Application may be downloaded.

Suggestion: App Store: an online location from which Untrusted Applications can be downloaded.

> like: "TEE Certificate Expiry and Renewal".  There is an earlier section that talks about expiration of Root CA certificates.
> 
> [Hannes] Makes sense.
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
> This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.--
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 7 Apr 2022 13:52:45 -0700

Hi Russ,

Great, thank you. Please see inline. I will update RFC with the two points
agreed.

Best,

Ming

On Thu, Apr 7, 2022 at 12:31 PM Russ Housley <[email-masked]> wrote:

> Please see below.
>
> On Apr 6, 2022, at 8:54 PM, Mingliang Pei <
> mingliang.pei=[email-masked]> wrote:
>
> [Ming] Trust Anchor definition says "The Trust Anchor may be a
> certificate or it may be a raw public key.". When it is a certificate, it
> doesn't have to be the root certificate. It could be an issuing CA while it
> isn't a common practice. Do we limit it to a self-signed root CA? I am fine
> with this, and update accordingly.
>
>
> I think the point about not a "Root Certificate" in all situations is very
> helpful.  Please add that to the document.
>
>
Ming: will add a clarification line in the definition of "Trust Anchor"
that a "A Trust Anchor can be a non-root certificate when it is a
certificate.", and keep the original statement above.

>> There are two points.  First, the need for a protocol to address the
>> items listed earlier.  Second, where an existing domain-specific protocol
>> does not already exist, a new more general protocol is needed.
>>
Ming: thanks

> Applications can be downloaded.

Ming: looks better. I will use your version.

> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> destroy any printed copy of it.--
> last-call mailing list
> [email-masked]

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 7 Apr 2022 17:40:57 -0700

See PR: https://github.com/ietf-teep/architecture/pull/236, thanks, Ming

On Thu, Apr 7, 2022 at 1:52 PM Mingliang Pei <[email-masked]>
wrote:

>> certificate or it may be a raw public key.". When it is a certificate,
>> it doesn't have to be the root certificate. It could be an issuing CA while
>> it isn't a common practice. Do we limit it to a self-signed root CA? I am
>> fine with this, and update accordingly.
>>
>>
>> I think the point about not a "Root Certificate" in all situations is
>> very helpful.  Please add that to the document.
>>
>>
>>> [Hannes] Agree that the sentence should be simplified. You are also
>>> right by saying that a solution is available. I am not sure we should
>>> reference the solution in this document or in the protocol spec.
>>>

---

From: Carl Wallace <[email-masked]>
Date: Mon, 11 Apr 2022 09:08:37 -0400

From: TEEP <[email-masked]> on behalf of Mingliang Pei <mingliang.pei=[email-masked]>
Date: Thursday, April 7, 2022 at 8:40 PM
To: Russ Housley <[email-masked]>
Cc: Mingliang Pei <mingliang.pei=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>
Subject: Re: [Teep] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16

[CW] Is it a certainty that constraints will not be needed for trust anchors? The trust anchor definition references “associated data”, which would be used constrain use of the trust anchor. An option other than certificate or public key may would be needed if constraints may be defined (because constraints can’t be added to the certificate without breaking the signature and a raw public key has no means to express constraints). Perhaps, "The Trust Anchor may be a certificate, a raw public key or other structure, as appropriate." might be better to leave open the possibility of constraining a trust anchor. RFC5914 defines syntax that allows for associated data to be packaged alongside a public key or a certificate, as an example of an alternative.

<snip>

---

From: Mingliang Pei <[email-masked]>
Date: Mon, 11 Apr 2022 11:29:56 -0700

Hi Carl,

Good point, thanks. A trust anchor intends to allow associated constraint
information, which is implementation specific, along with the main
underlying key material being a public key or a certificate. For the
revised definition, instead of allowing "other structure as appropriate",
how about we still call out the core key material being a "certificate or
public key", and other information along with them as appropriate? In other
words, how about the following?

The Trust Anchor may be a certificate or a raw public key with optionally
other constraint information or extensions. The structure of Trust Anchors
is implementation specific."

Thanks,

Ming

On Mon, Apr 11, 2022 at 6:08 AM Carl Wallace <[email-masked]>
wrote:

>
>
> *From: *TEEP <[email-masked]> on behalf of Mingliang Pei
> <mingliang.pei=[email-masked]>
> *Date: *Thursday, April 7, 2022 at 8:40 PM
> *To: *Russ Housley <[email-masked]>
> *Cc: *Mingliang Pei <mingliang.pei=[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, Hannes Tschofenig <
> [email-masked]>
> *Subject: *Re: [Teep] [Last-Call] Artart last call review of
> draft-ietf-teep-architecture-16
>
>
>
> [CW] Is it a certainty that constraints will not be needed for trust
> anchors? The trust anchor definition references “associated data”, which
> would be used constrain use of the trust anchor. An option other than
> certificate or public key may would be needed if constraints may be defined
> (because constraints can’t be added to the certificate without breaking the
> signature and a raw public key has no means to express constraints).
> Perhaps, "The Trust Anchor may be a certificate, a raw public key or other
> structure, as appropriate." might be better to leave open the possibility
> of constraining a trust anchor. RFC5914 defines syntax that allows for
> associated data to be packaged alongside a public key or a certificate, as
> an example of an alternative.
>
>
>
> <snip>
>

---

From: Mingliang Pei <[email-masked]>
Date: Mon, 11 Apr 2022 12:23:05 -0700

Hi Carl,

Considering "associated data" is already described in the first part of the
definition for "used to constraint the types", I think your wording is fine.
The revised full definition will look as follows.

*Trust Anchor*: As defined in {{RFC6024}} and
{{I-D.ietf-suit-architecture}},
    "A trust anchor represents an authoritative entity via a public
    key and associated data.  The public key is used to verify digital
    signatures, and the associated data is used to constrain the types
    of information for which the trust anchor is authoritative.
    The Trust Anchor may be a certificate, a raw public key or other
structure,
    as appropriate. It can be a non-root certificate when it is a
certificate.

I made this to the PR now. Please review.

Thanks,

Ming

On Mon, Apr 11, 2022 at 11:29 AM Mingliang Pei <[email-masked]>
wrote:

>> [email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
>> "[email-masked]" <[email-masked]>, "
>> [email-masked]" <
>> [email-masked]>, Hannes Tschofenig <

---

From: Carl Wallace <[email-masked]>
Date: Mon, 11 Apr 2022 16:24:29 -0400

That sounds fine and addresses the minor concern that the previous language may have been a bit too specific. Thanks.

From: Mingliang Pei <[email-masked]>
Date: Monday, April 11, 2022 at 2:29 PM
To: Carl Wallace <[email-masked]>
Cc: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>
Subject: Re: [Teep] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16

Hi Carl,

Good point, thanks. A trust anchor intends to allow associated constraint information, which is implementation specific, along with the main underlying key material being a public key or a certificate. For the revised definition, instead of allowing "other structure as appropriate", how about we still call out the core key material being a "certificate or public key", and other information along with them as appropriate? In other words, how about the following?

The Trust Anchor may be a certificate or a raw public key with optionally other constraint information or extensions. The structure of Trust Anchors is implementation specific."

Thanks,

Ming

On Mon, Apr 11, 2022 at 6:08 AM Carl Wallace <[email-masked]> wrote:

<snip>

This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 11 Apr 2022 16:25:02 -0400

That’s good too. Thanks.

Date: Monday, April 11, 2022 at 3:23 PM

Hi Carl,

Considering "associated data" is already described in the first part of the definition for "used to constraint the types", I think your wording is fine.

Trust Anchor: As defined in {{RFC6024}} and {{I-D.ietf-suit-architecture}},

    The Trust Anchor may be a certificate, a raw public key or other structure, 

    as appropriate. It can be a non-root certificate when it is a certificate.

Thanks,

Ming

On Mon, Apr 11, 2022 at 11:29 AM Mingliang Pei <[email-masked]> wrote:

Hi Carl,

Thanks,

Ming

<snip>