Re: [Gen-art] [art] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16

[Paul Kyzivat <[e-mail]>]

I've been seeing this discussion of Russ' artart review.
But I have seen no discussion of my genart review of it. Did you perhaps 
not get it?

	Thanks,
	Paul

On 4/7/22 4:52 PM, Mingliang Pei wrote:
> 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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Please see below.
> 
>>     On Apr 6, 2022, at 8:54 PM, Mingliang Pei
>>     <mingliang.pei=[e-mail]
>>     <mailto:mingliang.pei=[e-mail]>> wrote:
>>
>>     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
>>     <[e-mail] <mailto:[e-mail]>> 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
>>         <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 <[e-mail]
>>         <mailto:[e-mail]>>
>>         Sent: Tuesday, March 29, 2022 12:08 AM
>>         To: [e-mail] <mailto:[e-mail]>
>>         Cc: [e-mail]
>>         <mailto:[e-mail]>;
>>         [e-mail] <mailto:[e-mail]>; [e-mail]
>>         <mailto:[e-mail]>
>>         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.
> 
>     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.
> 
>>         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?
> 
>     Definitions would resolve this comment.
> 
> 
> Ming: thanks
> 
>>
>>     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.
> 
> 
> Ming: looks better. I will use your version.
> 
> 
>>         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.--
>>     last-call mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/last-call
>>     <https://www.ietf.org/mailman/listinfo/last-call>
> 
> 
> 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.
> 
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art