Subject: [Drip] [draft-ietf-drip-arch-14]: Section 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Tue, 13 Jul 2021 19:34:14 +0000

4.1. UAS Remote Identifiers Problem Space

  *   Editor-note 7: To be more specific about the RID message header and payload structure, such as 1) list different type of BRID messages defined in ASTM F3411, 2) how many bytes for each filed. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/18
Shuai / Do we really want to repeat ourself about how ASTM define the RID message and size of each field?  The text here explain clearly what ASTM has been defined, not DRIP.
However, If that is preferable, , see the following yellow highlight text.  If not, I suggest we remove the note.

“The Broadcast RID data exchange faces extreme challenges due to the limitation of the demanding support for Bluetooth. The ASTM [F3411-19] defines the basic RID message which is expected to contain certain RID data and the Authentication message. Per ASTM, the Basic RID message can only have a maximum payload of 25 bytes and 20 bytes for UAS ID, which only left 3 bytes are left unused can be used by DRIP . The ASTM [F3411019] also specifies the maximum 201 bytes can be used for authentication message “

  *   Editor-note 8: is there a need to explain the how binding/proxy/ translation between the HHIT and X509? Should this be addressed in Arch- or solution?  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20
Shuai/  I don’t think we have reach an agreement where we should we address the binding between HHIT and X509.  The solution draft in https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07 does not even mention the binding between HHIT and X509. If we don’t have a solution for now, I suggest we remove the entire text mentioning the HHIT and X509 binding as follows:

“
An example of a technology that will fit within these limitations is an enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] using Hierarchical HITs (HHITs) for UAS RID [I-D.ietf-drip-rid]. As PKI with X.509 is being used in other systems with which UAS RID must interoperate (e.g. Discovery and Synchronization Service and any other communications involving USS) mappings between the more flexible but larger X.509 certificates and the HHIT-based structures can must be devised. This could be as in [RFC8002] or simply the HHIT as Subject Alternative Name (SAN) and no Distinguished Name (DN).
“

  *   Editor-note 9: to be more specific regarding how HHIT can only use as little as 84 bytes to address the crypto concern.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/21
Shuai/  refer to RID-07, https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5.   Do we need to repeat the same text here in arch-?   If we do, see proposal highlighted text:

“
self-attestation of the HHIT RID can be done in as little as 84 bytes, by avoiding an explicit encoding technology like ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This compressed attestation consists of only the HHIT (16 bytes), a timestamp (4 bytes), and the EdDSA signature (64 bytes) on them. To minimize the risk of replay, the UA SHOULD create a new Self Attestation, with a new timestamp, at least once a minute.  The UA MAY precompute these attestations and transmit during the recommended 1-minute window.  A shorter window of use lessens the risk of replay.
“

  *   Editor-note 10: to be more specific why 200 bytes is sufficient. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/22
Shuai/ @Card, Stu<mailto:[email-masked]> I know you have provided text in the Github, please see the following highlighted text. You think add more clarification if required.

“
The HHIT prefix and suiteID provide crypto agility and implicit encoding rules. Similarly, a self-attestation of the Hierarchical registration of the RID (an attestation of a RID third-party registration "certificate") can be done in 200 bytes which is the range of what ASTM [F3411-19] allows for the maximum payload size of 201 bytes (17 payload bytes in the first page of a paged Authentication Message + 23 payload bytes in each of up to 8 more pages). (See detailed in UAS RID [I-D.ietf-drip-rid]).
“

  *   Editor-note 11: Explain how HIT itself and HHIT registry address naming collision.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/25
Shuai/ Where should be address this?  It has been explained in https://datatracker.ietf.org/doc/html/rfc7343#appendix-A

  *   Editor-note 14: Good to have: adding match requirement numbering from requirement document https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30
Shuai/ This might be done after we have addressed all the comments in Section 4.

4.2. HIT as A Trustworthy DRIP Entity Identifier
Editor-note 15: general comments about rewrite of this section due to lack of coherence.
     Shuai/ I can only look at this later once we have no comments for section 4, maybe rewrite some of the sentence of Section 4.1 and 4.2.

4.3.  HHIT for DRIP Identifier Registration and Lookup

  *   https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26
  *   https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27
  *   https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28

Editor-note 12: more description regarding 1) Is that something we should address in the Arch- 2) if yes, then adding more text about how a trustable lookup is performed
Shuai/ I think that is explained in UAS-RID https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.4

---

From: Daniel Migault <[email-masked]>
Date: Wed, 14 Jul 2021 12:12:58 -0400

On Tue, Jul 13, 2021 at 3:34 PM shuaiizhao(Shuai Zhao) <
[email-masked]> wrote:

>    - *Editor-note 7:* To be more specific about the RID message header
>    and payload structure, such as 1) list different type of BRID messages
>    defined in ASTM F3411, 2) how many bytes for each filed.
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/18
>
> Shuai / Do we really want to repeat ourself about how ASTM define the RID
> message and size of each field?  The text here explain clearly what ASTM
> has been defined, not DRIP.
>
> “The Broadcast RID data exchange faces extreme challenges due to the
> limitation of the demanding support for Bluetooth. The ASTM [F3411-19]
> defines the basic RID message which is expected to contain certain RID data
> and the Authentication message. Per ASTM, the Basic RID message can only
> have a maximum payload of 25 bytes and 20 bytes for UAS ID, which only left
> 3 bytes are left unused can be used by DRIP . The ASTM [F3411019] also
> specifies the maximum 201 bytes can be used for authentication message “
>
>
>
I have no strong opinion. The details may belong to the rid draft, but on
the other hand it captures the idea that drip has to fit into a framework
defined by ASTM. If we want to have such wording counting the bytes we need
to be very specific. Currently, the text seems to say the payload is 25
bytes with a RID of 20 which leave 3 bytes left while a reader may expect
the number of bytes left to be 5.
If we want to be specific I would suggest the text below from Stu.
"""
 The most commonly cited length of ASTM F3411 Broadcast RID message
payloads is 25 bytes, including a 4 bit Message Type and 4 bit Version. The
Basic ID message has a 4 bit ID Type, 4 bit UA Type, 20 byte UAS ID and 3
reserved bytes. F3411 Authentication messages can be "paged" (segmented),
for up to 201 bytes of auth. data, the first of which is the Specific Auth.
Method (SAM) type.
  """

Another alternative that sounds reasonable to me is to mention that ASTM
defines a limit of 20 bytes for the UAS ID and 201 bytes for the
authentication message.

>    - *Editor-note 8:* is there a need to explain the how binding/proxy/
>    translation between the HHIT and X509? Should this be addressed in Arch- or
>    solution?
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20
>
> Shuai/  I don’t think we have reach an agreement where we should we
> address the binding between HHIT and X509.  The solution draft in
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07 does not
> even mention the binding between HHIT and X509. If we don’t have a solution
> for now, I suggest we remove the entire text mentioning the HHIT and X509
> binding as follows:
>
>
>
> “
>
> An example of a technology that will fit within these limitations is an
> enhancement of the Host Identity Tag (HIT) of HIPv2 [RFC7401] using
> Hierarchical HITs (HHITs) for UAS RID [I-D.ietf-drip-rid]. As PKI with
> X.509 is being used in other systems with which UAS RID must interoperate
> (e.g. Discovery and Synchronization Service and any other communications
> involving USS) mappings between the more flexible but larger X.509
> certificates and the HHIT-based structures can must be devised. This could
> be as in [RFC8002] or simply the HHIT as Subject Alternative Name (SAN) and
> no Distinguished Name (DN).
>
> “
>
> I agree this is not necessary.

>
>
>    - *Editor-note 9:* to be more specific regarding how HHIT can only use
>    as little as 84 bytes to address the crypto concern.
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/21
>
> Shuai/  refer to RID-07,
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5.
>   Do we need to repeat the same text here in arch-?   If we do, see
> proposal highlighted text:
>
>
>
> “
>
> self-attestation of the HHIT RID can be done in as little as 84 bytes, by
> avoiding an explicit encoding technology like ASN.1 or Concise Binary
> Object Representation (CBOR [RFC8949]). This compressed attestation
> consists of only the HHIT (16 bytes), a timestamp (4 bytes), and the
> EdDSA signature (64 bytes) on them. To minimize the risk of replay, the
> UA SHOULD create a new Self Attestation, with a new timestamp, at least
> once a minute.  The UA MAY precompute these attestations and transmit
> during the recommended 1-minute window.  A shorter window of use lessens
> the risk of replay.
>
> “
>
I think the important information is the specific format we use for the
attestation:
This compressed attestation consists of only the HHIT (16 bytes), a
timestamp (4 bytes), and the EdDSA signature (64 bytes) on them.

I do not see this as a "compressed" attestation, it is rather the format we
are using so I would remove "compressed". It seems important the reader get
how to check the signature and be convinced the attestation is trustworthy.
- how to I check the signature ? how do a trust this is the valid key,
signature, informations...

That we do not use ASN1 or CBOR becomes obvious. It may be useful to be
specified. That we can achieve in 84 bytes is also informational and we
need to expose in which condition this is achieved. I am unsure how useful
this is given that we do not provide the numbers for the other protocols.
It might make the reading more complex and dive into too many unnecessary
details in my opinion.

I think that how anti replay is addressed is useful.  I am not sure that
security consideration or this section is the right place, but I might
personally leave it there. I would maybe describe what the replay attack
consists in before explaining why we are immune to it.

>
>
>    - *Editor-note 10:* to be more specific why 200 bytes is sufficient.
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/22
>
> Shuai/ @Card, Stu <[email-masked]> I know you have provided
> text in the Github, please see the following highlighted text. You think
> add more clarification if required.
>
>
>
> “
>
> The HHIT prefix and suiteID provide crypto agility and implicit encoding
> rules. Similarly, a self-attestation of the Hierarchical registration of
> the RID (an attestation of a RID third-party registration "certificate")
> can be done in 200 bytes which is the range of what ASTM [F3411-19]
> allows for the maximum payload size of 201 bytes (17 payload bytes in the
> first page of a paged Authentication Message + 23 payload bytes in each of
> up to 8 more pages). (See detailed in UAS RID [I-D.ietf-drip-rid]).
>
> “
>
>
>
I do see this as the constraints put on rid. My impression is that this
goes beyond the scope of the architecture to explain the solution fits
these requirements. Of course this is a strong requirement, but I do see it
more in the solution space. Of course if that were impossible the
architecture could not be implemented.

>
>    - *Editor-note 11*: Explain how HIT itself and HHIT registry address
>    naming collision.
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/25
>
> Shuai/ Where should be address this?  It has been explained in
> https://datatracker.ietf.org/doc/html/rfc7343#appendix-A
>
>
>
As far as I remember the argument is provided in the main text, and I do
believe that the reasoning can be provided in the main text. The appendix
might be needed only if there are too many details that are architecture
related as opposed to solution space related.

>
>    - *Editor-note 14:* Good to have: adding match requirement numbering
>    from requirement document
>    https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30
>
> *Editor-note 15:* general comments about rewrite of this section due to
> lack of coherence.
>
>      Shuai/ I can only look at this later once we have no comments for
> section 4, maybe rewrite some of the sentence of Section 4.1 and 4.2.
>
>
>
>
>
>    - https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26
>    - https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27
>    - https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28
>
>
> *Editor-note 12:* more description regarding 1) Is that something we
> should address in the Arch- 2) if yes, then adding more text about how a
> trustable lookup is performed
>
> Shuai/ I think that is explained in UAS-RID
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.4
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
Daniel Migault
Ericsson

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Sun, 18 Jul 2021 23:08:11 +0000

Hi Daniel, please see reply inline.

Resolved 7, 8, 9, 10, 11 and 15. Let me know if proposed changes are good to you

Still have note 12 and 14. Will do it next round.

Best,
Shuai

From: Daniel Migault <[email-masked]>
Date: Wednesday, July 14, 2021 at 9:13 AM
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Moskowitz <[email-masked]>, Robert Moskowitz <[email-masked]>, "Card, Stu" <[email-masked]>
Subject: [Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15

On Tue, Jul 13, 2021 at 3:34 PM shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>> wrote:

·      Editor-note 7: To be more specific about the RID message header and payload structure, such as 1) list different type of BRID messages defined in ASTM F3411, 2) how many bytes for each filed. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/18
Shuai / Do we really want to repeat ourself about how ASTM define the RID message and size of each field?  The text here explain clearly what ASTM has been defined, not DRIP.
However, If that is preferable, , see the following yellow highlight text.  If not, I suggest we remove the note.

I have no strong opinion. The details may belong to the rid draft, but on the other hand it captures the idea that drip has to fit into a framework defined by ASTM. If we want to have such wording counting the bytes we need to be very specific. Currently, the text seems to say the payload is 25 bytes with a RID of 20 which leave 3 bytes left while a reader may expect the number of bytes left to be 5.
If we want to be specific I would suggest the text below from Stu.
"""
 The most commonly cited length of ASTM F3411 Broadcast RID message payloads is 25 bytes, including a 4 bit Message Type and 4 bit Version. The Basic ID message has a 4 bit ID Type, 4 bit UA Type, 20 byte UAS ID and 3 reserved bytes. F3411 Authentication messages can be "paged" (segmented), for up to 201 bytes of auth. data, the first of which is the Specific Auth. Method (SAM) type.
  """

Another alternative that sounds reasonable to me is to mention that ASTM defines a limit of 20 bytes for the UAS ID and 201 bytes for the authentication message.
<shuai>
                At this point, I have heard 3 different versions of proposals, some like more details, some are don’t.
                Lets keep the text I have proposed blew and see how reviews coming back. Agreeable?  If someone likes more details, we can easily add it back….

The Broadcast RID data exchange faces extreme challenges due to the
   limitation of the demanding support for Bluetooth.  The ASTM
   [F3411-19] defines the basic RID message which is expected to contain
   certain RID data and the Authentication message.  The Basic RID
   message has a maximum payload of 25 bytes and only 3 reserved bytes
   are left unused. currently, the authentication maximum payload is
   defined to be 201 bytes.
</shuai>
·      Editor-note 8: is there a need to explain the how binding/proxy/ translation between the HHIT and X509? Should this be addressed in Arch- or solution?  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20
Shuai/  I don’t think we have reach an agreement where we should we address the binding between HHIT and X509.  The solution draft in https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07 does not even mention the binding between HHIT and X509. If we don’t have a solution for now, I suggest we remove the entire text mentioning the HHIT and X509 binding as follows:

“

<shuai>
                Removed above text and note #8
</shuai>

·      Editor-note 9: to be more specific regarding how HHIT can only use as little as 84 bytes to address the crypto concern.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/21
Shuai/  refer to RID-07, https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5.   Do we need to repeat the same text here in arch-?   If we do, see proposal highlighted text:

“
self-attestation of the HHIT RID can be done in as little as 84 bytes, by avoiding an explicit encoding technology like ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This compressed attestation consists of only the HHIT (16 bytes), a timestamp (4 bytes), and the EdDSA signature (64 bytes) on them. To minimize the risk of replay, the UA SHOULD create a new Self Attestation, with a new timestamp, at least once a minute.  The UA MAY precompute these attestations and transmit during the recommended 1-minute window.  A shorter window of use lessens the risk of replay.
“
I think the important information is the specific format we use for the attestation:
This compressed attestation consists of only the HHIT (16 bytes), a timestamp (4 bytes), and the EdDSA signature (64 bytes) on them.

I do not see this as a "compressed" attestation, it is rather the format we are using so I would remove "compressed". It seems important the reader get how to check the signature and be convinced the attestation is trustworthy. - how to I check the signature ? how do a trust this is the valid key, signature, informations...

That we do not use ASN1 or CBOR becomes obvious. It may be useful to be specified. That we can achieve in 84 bytes is also informational and we need to expose in which condition this is achieved. I am unsure how useful this is given that we do not provide the numbers for the other protocols. It might make the reading more complex and dive into too many unnecessary details in my opinion.

I think that how anti replay is addressed is useful.  I am not sure that security consideration or this section is the right place, but I might personally leave it there. I would maybe describe what the replay attack consists in before explaining why we are immune to it.

<shuai>
                I will remove “compressed”; I don’t even realize that is THE problem until now.  I agree some data point comparison might be helpful.
                Per comments from Daniel, I will close #9. However, keep a record that more details MAYBE need, such as mentioned above.

</shuai>

·      Editor-note 10: to be more specific why 200 bytes is sufficient. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/22
Shuai/ @Card, Stu<mailto:[email-masked]> I know you have provided text in the Github, please see the following highlighted text. You think add more clarification if required.

“

I do see this as the constraints put on rid. My impression is that this goes beyond the scope of the architecture to explain the solution fits these requirements. Of course this is a strong requirement, but I do see it more in the solution space. Of course if that were impossible the architecture could not be implemented.

<shuai>
                Current comments let me believe we should remove this sentence. We should not mention how HHIT is doing crypto in technical details.
                Remove the following and Editor-note

The HHIT prefix and suiteID provide crypto agility and implicit encoding rules. Similarly, a self-attestation of the Hierarchical registration of the RID (an attestation of a RID third-party registration "certificate") can be done in 200 bytes.  Both these are detailed in UAS RID {{I-D.ietf-drip-rid}}.

> Editor-note 10: to be more specific why 200 bytes is sufficient.

</shuai>

·      Editor-note 11: Explain how HIT itself and HHIT registry address naming collision.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/25
Shuai/ Where should be address this?  It has been explained in https://datatracker.ietf.org/doc/html/rfc7343#appendix-A

As far as I remember the argument is provided in the main text, and I do believe that the reasoning can be provided in the main text. The appendix might be needed only if there are too many details that are architecture related as opposed to solution space related.

<shuai>
                I don’t see Why need to explain how HIT handles collisions. It’s all in both RFC5730 and RID draft.

                I will remove 11 unless I heard more detailed comments on this.
</shuai>
·      Editor-note 14: Good to have: adding match requirement numbering from requirement document https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30
Shuai/ This might be done after we have addressed all the comments in Section 4.

4.2. HIT as A Trustworthy DRIP Entity Identifier
Editor-note 15: general comments about rewrite of this section due to lack of coherence.
     Shuai/ I can only look at this later once we have no comments for section 4, maybe rewrite some of the sentence of Section 4.1 and 4.2.
 <shuai>
Updated is made. Anything regards HIT have been put in 4.2  HIT as A Trustworthy DRIP Entity Identifier
Remove note 15, if you see a particular sentence needed attention, please let me know.
</shuai>

4.3.  HHIT for DRIP Identifier Registration and Lookup
·      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26
·      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27
·      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

--
Daniel Migault
Ericsson

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 21 Jul 2021 16:20:06 +0000

Updated from Bob regarding Editor note 12:

> Editor-note 12: more description regarding trustable lookup 1) Is that something we should address in the Arch- 2) if yes, then adding more text about how a trustable lookup is performed

   Remote ID needs a deterministic lookup mechanism that rapidly
   provides actionable information about the identified UA.  Given the
   size constraints imposed by the Bluetooth 4 broadcast media, the
   Remote ID itself needs to be a non-spoofable inquiry input into the
   lookup.

   A DRIP registration process based on the explicit hierarchy within a
   HHIT provides manageable uniqueness of the HI for the HHIT (defense
  against a cryptographic hash second pre-image attack on the HHIT;
   e.g. multiple HIs yielding the same HHIT).  A lookup of the HHIT into
   this registration data provides the registered HI for HHIT proof.  A
   first-come-first-serve registration for a HHIT provides deterministic
   access to any other needed actionable information based on inquiry
   access authority (more details in Section 5.2).

please comment then I can close ED 12.

Best,
Shuai

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Sunday, July 18, 2021 at 4:08 PM
To: "[email-masked]" <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>, Robert Moskowitz <[email-masked]>, "Card, Stu" <[email-masked]>, Daniel Migault <[email-masked]>
Subject: Re: [Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15

Best,
Shuai

“

<shuai>

“

<shuai>

</shuai>

“

<shuai>

</shuai>

<shuai>

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Jul 2021 13:17:15 -0400

Hi Shuai,

Thanks for the follow-up. Please close the issues that have been resolved
by your new version and see my comments in line.

Yours,
Daniel

On Sun, Jul 18, 2021 at 7:08 PM shuaiizhao(Shuai Zhao) <
[email-masked]> wrote:

> *From: *Daniel Migault <[email-masked]>
> *Date: *Wednesday, July 14, 2021 at 9:13 AM
> *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Robert Moskowitz <
> [email-masked]>, Robert Moskowitz <[email-masked]>, "Card,
> Stu" <[email-masked]>
> *Subject: *[Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 4.1,
> 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15
>
>
>
>
>
>
>
> ·      *Editor-note 7:* To be more specific about the RID message header
>                 At this point, I have heard 3 different versions of
> proposals, some like more details, some are don’t.
>
>                 Lets keep the text I have proposed blew and see how
> reviews coming back. Agreeable?  If someone likes more details, we can
> easily add it back….
>
>
>
I think the most important information is that *we* at the IETF have been
provided a 20 byte limit for the RID by ASTM and other information seems to
me mostly informative. I see this information missing in the proposed text
which makes me think we may have missed something.

> ·      *Editor-note 8:* is there a need to explain the how binding/proxy/
> solution?  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20
>

works fine to me.

>
>
> ·      *Editor-note 9:* to be more specific regarding how HHIT can only
> use as little as 84 bytes to address the crypto concern.
> I do not see this as a "compressed" attestation, it is rather the format
> we are using so I would remove "compressed". It seems important the reader
> get how to check the signature and be convinced the attestation is
> trustworthy. - how to I check the signature ? how do a trust this is the
> valid key, signature, informations...
>
>
>
>                 I will remove “compressed”; I don’t even realize that is
> THE problem until now.  I agree some data point comparison might be
> helpful.
>
>                 Per comments from Daniel, I will close #9. However, keep a
> record that more details MAYBE need, such as mentioned above.
>
>
>
> </shuai>
>
sounds reasonable -- at least for the next version. If you keep the byte
number, please indicate  64 byte corresponds to Ed25519 and is taken as an
example.

>
>
> ·      *Editor-note 10:* to be more specific why 200 bytes is sufficient.
>                 Current comments let me believe we should remove this
> sentence. We should not mention how HHIT is doing crypto in technical
> details.
>
> can be done in 200 bytes.  Both these are detailed in UAS RID
> {{I-D.ietf-drip-rid}}.
>
>
>
> sounds reasonable.

>
>
> ·      *Editor-note 11*: Explain how HIT itself and HHIT registry address
> naming collision.
>                 I don’t see Why need to explain how HIT handles
> collisions. It’s all in both RFC5730 and RID draft.
>
>
>
We do not necessarily say how it deals with collision but we need to said
RID design prevents the collision between two registries.

> ·      *Editor-note 14:* Good to have: adding match requirement numbering
> sure, but that will be needed at some points - at least as an appendix.

> let's see how it shows up in the next version.

> It seems to me that at the architecture level we need to have a clear idea
on what type of information will each registry have, how registration
happens, and how information are retrieved. This seems essential to me at
least to be able to validate the RID. This can be done in the future
version.

-- 
Daniel Migault
Ericsson

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 21 Jul 2021 13:34:18 -0400

Good.

On 7/21/21 12:20 PM, shuaiizhao(Shuai Zhao) wrote:
> > Editor-note 12: more description regarding trustable lookup 1) Is 
> that something we should address in the Arch- 2) if yes, then adding 
> more text about how a trustable lookup is performed
>
> *From: *"shuaiizhao(Shuai Zhao)" <[email-masked]>
> *Date: *Sunday, July 18, 2021 at 4:08 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Robert Moskowitz <[email-masked]>, Robert Moskowitz 
> <[email-masked]>, "Card, Stu" <[email-masked]>, Daniel 
> Migault <[email-masked]>
> *Subject: *Re: [Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 
> 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15
>
> *Cc: *"[email-masked]" <[email-masked]>, Robert Moskowitz 
> <[email-masked]>, Robert Moskowitz <[email-masked]>, 
> "Card, Stu" <[email-masked]>
> *Subject: *[Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 
> 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15
>
> On Tue, Jul 13, 2021 at 3:34 PM shuaiizhao(Shuai Zhao) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     page5image18635520page5image18635712
>
>     ·_Editor-note 7:_To be more specific about the RID message header
>     and payload structure, such as 1) list different type of BRID
>     messages defined in ASTM F3411, 2) how many bytes for each filed.
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/18>
>
>     Shuai / Do we really want to repeat ourself about how ASTM define
>     the RID message and size of each field?  The text here explain
>     clearly what ASTM has been defined, not DRIP.
>
>     However, If that is preferable, , see the following yellow
>     highlight text.  If not, I suggest we remove the note.
>
>     “The Broadcast RID data exchange faces extreme challenges due to
>     the limitation of the demanding support for Bluetooth. The ASTM
>     [F3411-19] defines the basic RID message which is expected to
>     contain certain RID data and the Authentication message. Per ASTM,
>     the Basic RID message can only have a maximum payload of 25 bytes
>     and 20 bytes for UAS ID, which only left 3 bytes are left unused
>     can be used by DRIP . The ASTM [F3411019] also specifies the
>     maximum 201 bytes can be used for authentication message “
>
> I have no strong opinion. The details may belong to the rid draft, but 
> on the other hand it captures the idea that drip has to fit into a 
> framework defined by ASTM. If we want to have such wording counting 
> the bytes we need to be very specific. Currently, the text seems to 
> say the payload is 25 bytes with a RID of 20 which leave 3 bytes left 
> while a reader may expect the number of bytes left to be 5.
>
> payloads is 25 bytes, including a 4 bit Message Type and 4 bit 
> Version. The Basic ID message has a 4 bit ID Type, 4 bit UA Type, 20 
> byte UAS ID and 3 reserved bytes. F3411 Authentication messages can be 
> "paged" (segmented), for up to 201 bytes of auth. data, the first of 
> which is the Specific Auth. Method (SAM) type.
>
>   """
>
> Another alternative that sounds reasonable to me is to mention that 
> ASTM defines a limit of 20 bytes for the UAS ID and 201 bytes for the 
> authentication message.
>
> <shuai>
>
> are left unused.currently, the authentication maximum payload is
>
> defined to be 201 bytes.
>
> </shuai>
>
>     ·_Editor-note 8:_is there a need to explain the how binding/proxy/
>     translation between the HHIT and X509? Should this be addressed in
>     Arch- or solution?
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20>
>
>     Shuai/  I don’t think we have reach an agreement where we should
>     we address the binding between HHIT and X509.  The solution draft
>     in https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07
>     <https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07>
>     does not even mention the binding between HHIT and X509. If we
>     don’t have a solution for now, I suggest we remove the entire text
>     mentioning the HHIT and X509 binding as follows:
>
>     “
>
>     An example of a technology that will fit within these limitations
>     is an enhancement of the Host Identity Tag (HIT) of HIPv2
>     [RFC7401] using Hierarchical HITs (HHITs) for UAS RID
>     [I-D.ietf-drip-rid]. As PKI with X.509 is being used in other
>     systems with which UAS RID must interoperate (e.g. Discovery and
>     Synchronization Service and any other communications involving
>     USS) mappings between the more flexible but larger X.509
>     certificates and the HHIT-based structures can must be devised.
>     This could be as in [RFC8002] or simply the HHIT as Subject
>     Alternative Name (SAN) and no Distinguished Name (DN).
>
>     “
>
>     ·_Editor-note 9:_to be more specific regarding how HHIT can only
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/21>
>
>     Shuai/  refer to RID-07,
>     https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5
>     <https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5>.
>       Do we need to repeat the same text here in arch-?   If we do,
>     see proposal highlighted text:
>
>     “
>
>     self-attestation of the HHIT RID can be done in as little as 84
>     bytes, by avoiding an explicit encoding technology like ASN.1 or
>     Concise Binary Object Representation (CBOR [RFC8949]). This
>     compressed attestation consists of only the HHIT (16 bytes), a
>     To minimize the risk of replay, the UA SHOULD create a new Self
>     Attestation, with a new timestamp, at least once a minute.  The UA
>     MAY precompute these attestations and transmit during the
>     recommended 1-minute window.  A shorter window of use lessens the
>     risk of replay.
>
>     “
>
> I do not see this as a "compressed" attestation, it is rather the 
> format we are using so I would remove "compressed". It seems important 
> the reader get how to check the signature and be convinced the 
> attestation is trustworthy. - how to I check the signature ? how do a 
> trust this is the valid key, signature, informations...
>
> That we do not use ASN1 or CBOR becomes obvious. It may be useful to 
> be specified. That we can achieve in 84 bytes is also informational 
> and we need to expose in which condition this is achieved. I am unsure 
> how useful this is given that we do not provide the numbers for the 
> other protocols. It might make the reading more complex and dive into 
> too many unnecessary details in my opinion.
>
> I think that how anti replay is addressed is useful.  I am not sure 
> that security consideration or this section is the right place, but I 
> might personally leave it there. I would maybe describe what the 
> replay attack consists in before explaining why we are immune to it.
>
> <shuai>
>
>                 I will remove “compressed”; I don’t even realize that 
> is THE problem until now.  I agree some data point comparison might be 
> helpful.
>
>                 Per comments from Daniel, I will close #9. However, 
> keep a record that more details MAYBE need, such as mentioned above.
>
> </shuai>
>
>     ·_Editor-note 10:_to be more specific why 200 bytes is sufficient.
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/22>
>
>     Shuai/ @Card, Stu <mailto:[email-masked]> I know you
>     have provided text in the Github, please see the following
>     highlighted text. You think add more clarification if required.
>
>     “
>
>     The HHIT prefix and suiteID provide crypto agility and implicit
>     encoding rules. Similarly, a self-attestation of the Hierarchical
>     registration of the RID (an attestation of a RID third-party
>     registration "certificate") can be done in 200 bytes which is the
>     range of what ASTM [F3411-19] allows for the maximum payload size
>     of 201 bytes (17 payload bytes in the first page of a paged
>     Authentication Message + 23 payload bytes in each of up to 8 more
>     pages). (See detailed in UAS RID [I-D.ietf-drip-rid]).
>
>     “
>
> I do see this as the constraints put on rid. My impression is that 
> this goes beyond the scope of the architecture to explain the solution 
> fits these requirements. Of course this is a strong requirement, but I 
> do see it more in the solution space. Of course if that were 
> impossible the architecture could not be implemented.
>
> <shuai>
>
> The HHIT prefix and suiteID provide crypto agility and implicit 
> encoding rules. Similarly, a self-attestation of the Hierarchical 
> registration of the RID (an attestation of a RID third-party 
> registration "certificate") can be done in 200 bytes.  Both these are 
> detailed in UAS RID {{I-D.ietf-drip-rid}}.
>
>     ·_Editor-note 11_: Explain how HIT itself and HHIT registry
>     address naming collision.
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/25>
>
>     <https://datatracker.ietf.org/doc/html/rfc7343#appendix-A>
>
> As far as I remember the argument is provided in the main text, and I 
> do believe that the reasoning can be provided in the main text. The 
> appendix might be needed only if there are too many details that are 
> architecture related as opposed to solution space related.
>
> <shuai>
>
>     ·_Editor-note 14:_Good to have: adding match requirement numbering
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30>
>
>     _Editor-note 15:_general comments about rewrite of this section
>     due to lack of coherence.
>
>          Shuai/ I can only look at this later once we have no comments
>     for section 4, maybe rewrite some of the sentence of Section 4.1
>     and 4.2.
>
>     <shuai>
>
>     ·https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26>
>
>     ·https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27>
>
>     ·https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28
>     <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28>
>
>
>     _Editor-note 12:_ more description regarding 1) Is that something
>     we should address in the Arch- 2) if yes, then adding more text
>     about how a trustable lookup is performed
>
>     <https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.4>
>
>     -- 
>     Tm-rid mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>
> -- 
>
> Daniel Migault
>
> Ericsson
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 21 Jul 2021 13:55:48 -0400

Inline....

On 7/21/21 1:17 PM, Daniel Migault wrote:
> Hi Shuai,
>
> Thanks for the follow-up. Please close the issues that have been 
> resolved by your new version and see my comments in line.
>
> Yours,
> Daniel
>
> On Sun, Jul 18, 2021 at 7:08 PM shuaiizhao(Shuai Zhao) 
>     *From: *Daniel Migault <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *"shuaiizhao(Shuai Zhao)" <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, Robert Moskowitz
>     <[email-masked] <mailto:[email-masked]>>,
>     Robert Moskowitz <[email-masked]
>     <mailto:[email-masked]>>, "Card, Stu"
>     <[email-masked] <mailto:[email-masked]>>
>         ·_Editor-note 7:_To be more specific about the RID message
>         header and payload structure, such as 1) list different type
>         of BRID messages defined in ASTM F3411, 2) how many bytes for
>         each filed.
>         Shuai / Do we really want to repeat ourself about how ASTM
>         define the RID message and size of each field?  The text here
>         explain clearly what ASTM has been defined, not DRIP.
>
>         “The Broadcast RID data exchange faces extreme challenges due
>         to the limitation of the demanding support for Bluetooth. The
>         ASTM [F3411-19] defines the basic RID message which is
>         expected to contain certain RID data and the Authentication
>         message. Per ASTM, the Basic RID message can only have a
>         maximum payload of 25 bytes and 20 bytes for UAS ID, which
>         only left 3 bytes are left unused can be used by DRIP . The
>         ASTM [F3411019] also specifies the maximum 201 bytes can be
>         used for authentication message “
>
>     I have no strong opinion. The details may belong to the rid draft,
>     but on the other hand it captures the idea that drip has to fit
>     into a framework defined by ASTM. If we want to have such wording
>     counting the bytes we need to be very specific. Currently, the
>     text seems to say the payload is 25 bytes with a RID of 20
>     which leave 3 bytes left while a reader may expect the number of
>     bytes left to be 5.
>
>      The most commonly cited length of ASTM F3411 Broadcast RID
>     message payloads is 25 bytes, including a 4 bit Message Type and 4
>     bit Version. The Basic ID message has a 4 bit ID Type, 4 bit UA
>     Type, 20 byte UAS ID and 3 reserved bytes. F3411 Authentication
>     messages can be "paged" (segmented), for up to 201 bytes of auth.
>     data, the first of which is the Specific Auth. Method (SAM) type.
>
>     """
>
>     Another alternative that sounds reasonable to me is to mention
>     that ASTM defines a limit of 20 bytes for the UAS ID and 201 bytes
>     for the authentication message.
>
>     <shuai>
>
>     Lets keep the text I have proposed blew and see how reviews coming
>     back. Agreeable?  If someone likes more details, we can easily add
>     it back….
>
> I think the most important information is that *we* at the IETF have 
> been provided a 20 byte limit for the RID by ASTM and other 
> information seems to me mostly informative. I see this information 
> missing in the proposed text which makes me think we may have missed 
> something.

And when F3411-21 is published, we will be squeezed down to 19 bytes.  
(the balloting is 'cooked' as anyone that has something to say, said it 
in the calls that led to the balloted ver).

ID Type 4 will be "Session ID".  Type 3 UUID, although a session id, 
will remain due to existing implementations.  But IETF will get Specific 
ID 1 and 3GPP's 1609.2 proposal gets Specific ID 2.

We should drop the text about 3 bytes unused.

>         ·_Editor-note 8:_is there a need to explain the how
>         binding/proxy/ translation between the HHIT and X509? Should
>         this be addressed in Arch- or solution?
>         Shuai/  I don’t think we have reach an agreement where we
>         should we address the binding between HHIT and X509.  The
>         solution draft in
>         https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07
>         don’t have a solution for now, I suggest we remove the entire
>         text mentioning the HHIT and X509 binding as follows:
>
>         “
>
>         An example of a technology that will fit within these
>         limitations is an enhancement of the Host Identity Tag (HIT)
>         of HIPv2 [RFC7401] using Hierarchical HITs (HHITs) for UAS RID
>         systems with which UAS RID must interoperate (e.g. Discovery
>         and Synchronization Service and any other communications
>         involving USS) mappings between the more flexible but larger
>         X.509 certificates and the HHIT-based structures can must be
>         devised. This could be as in [RFC8002] or simply the HHIT as
>         Subject Alternative Name (SAN) and no Distinguished Name (DN).
>
>         “
>

You mean after all I spent to try and fix it?  :)

>         ·_Editor-note 9:_to be more specific regarding how HHIT can
>         only use as little as 84 bytes to address the crypto concern.
>           Do we need to repeat the same text here in arch-?   If we
>         do, see proposal highlighted text:
>
>         “
>
>         self-attestation of the HHIT RID can be done in as little as
>         84 bytes, by avoiding an explicit encoding technology like
>         ASN.1 or Concise Binary Object Representation (CBOR
>         [RFC8949]). This compressed attestation consists of only the
>         HHIT (16 bytes), a timestamp (4 bytes), and the EdDSA
>         signature (64 bytes) on them. To minimize the risk of replay,
>         the UA SHOULD create a new Self Attestation, with a new
>         timestamp, at least once a minute.  The UA MAY precompute
>         these attestations and transmit during the recommended
>         1-minute window.  A shorter window of use lessens the risk of
>         replay.
>
>         “
>
>     This compressed attestation consists of only the HHIT (16 bytes),
>     a timestamp (4 bytes), and the EdDSA signature (64 bytes) on them.
>
>     format we are using so I would remove "compressed". It seems
>     important the reader get how to check the signature and be
>     convinced the attestation is trustworthy. - how to I check the
>     signature ? how do a trust this is the valid key, signature,
>     informations...
>
>     That we do not use ASN1 or CBOR becomes obvious. It may be useful
>     to be specified. That we can achieve in 84 bytes is also
>     informational and we need to expose in which condition this is
>     achieved. I am unsure how useful this is given that we do not
>     provide the numbers for the other protocols. It might make the
>     reading more complex and dive into too many unnecessary details in
>     my opinion.
>
>     I think that how anti replay is addressed is useful.  I am not
>     sure that security consideration or this section is the right
>     place, but I might personally leave it there. I would maybe
>     describe what the replay attack consists in before explaining
>     why we are immune to it.
>
>     <shuai>
>
>                     I will remove “compressed”; I don’t even realize
>     that is THE problem until now.  I agree some data point comparison
>     might be helpful.
>
>     Per comments from Daniel, I will close #9. However, keep a record
>     that more details MAYBE need, such as mentioned above.
>
>     </shuai>
>
> sounds reasonable -- at least for the next version. If you keep the 
> byte number, please indicate  64 byte corresponds to Ed25519 and is 
> taken as an example.
>
>         Shuai/ @Card, Stu <mailto:[email-masked]> I know
>         you have provided text in the Github, please see the following
>         The HHIT prefix and suiteID provide crypto agility and
>         implicit encoding rules. Similarly, a self-attestation of the
>         Hierarchical registration of the RID (an attestation of a RID
>         third-party registration "certificate") can be done in 200
>         bytes which is the range of what ASTM [F3411-19] allows for
>         the maximum payload size of 201 bytes (17 payload bytes in the
>         first page of a paged Authentication Message + 23 payload
>         bytes in each of up to 8 more pages). (See detailed in UAS RID
>         [I-D.ietf-drip-rid]).
>
>         “
>
>     this goes beyond the scope of the architecture to explain the
>     solution fits these requirements. Of course this is a strong
>     requirement, but I do see it more in the solution space. Of course
>     if that were impossible the architecture could not be implemented.
>
>     <shuai>
>
>     Current comments let me believe we should remove this sentence. We
>     should not mention how HHIT is doing crypto in technical details.
>
>     registration "certificate") can be done in 200 bytes.  Both these
>     are detailed in UAS RID {{I-D.ietf-drip-rid}}.
>
>     As far as I remember the argument is provided in the main text,
>     and I do believe that the reasoning can be provided in the main
>     text. The appendix might be needed only if there are too many
>     details that are architecture related as opposed to solution space
>     related.
>
>     <shuai>
>
> We do not necessarily say how it deals with collision but we need to 
> said RID design prevents the collision between two registries.
>
>         ·_Editor-note 14:_Good to have: adding match requirement
>         numbering from requirement document
>         _Editor-note 15:_general comments about rewrite of this
>         section due to lack of coherence.
>
>              Shuai/ I can only look at this later once we have no
>         comments for section 4, maybe rewrite some of the sentence of
>         Section 4.1 and 4.2.
>
>         <shuai>
>
>         Updated is made. Anything regards HIT have been put in 4.2
>          HIT as A Trustworthy DRIP Entity Identifier
>
>         _Editor-note 12:_ more description regarding 1) Is that
>         something we should address in the Arch- 2) if yes, then
>         adding more text about how a trustable lookup is performed
>
> It seems to me that at the architecture level we need to have a clear 
> idea on what type of information will each registry have, how 
> registration happens, and how information are retrieved. This seems 
> essential to me at least to be able to validate the RID. This can be 
> done in the future version.
>
>         -- 
>         Tm-rid mailing list

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 21 Jul 2021 19:14:19 +0000

Please see inline.

From: Robert Moskowitz <[email-masked]>
Date: Wednesday, July 21, 2021 at 10:57 AM
To: Daniel Migault <[email-masked]>, "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Moskowitz <[email-masked]>, "Card, Stu" <[email-masked]>
Subject: [Internet]Re: [Drip] Re: [draft-ietf-drip-arch-14]: Section 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15

Inline....

Thanks for the follow-up. Please close the issues that have been resolved by your new version and see my comments in line.

Yours,
Daniel

On Sun, Jul 18, 2021 at 7:08 PM shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel, please see reply inline.

Best,
Shuai

From: Daniel Migault <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 14, 2021 at 9:13 AM
To: "shuaiizhao(Shuai Zhao)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Robert Moskowitz <[email-masked]<mailto:[email-masked]>>, Robert Moskowitz <[email-masked]<mailto:[email-masked]>>, "Card, Stu" <[email-masked]<mailto:[email-masked]>>
Subject: [Internet]Re: [Drip] [draft-ietf-drip-arch-14]: Section 4.1, 4.2, 4.3 Resolve Editor-note #7, #8, #9, #10, #11, #12, #14 and #15

•      Editor-note 7: To be more specific about the RID message header and payload structure, such as 1) list different type of BRID messages defined in ASTM F3411, 2) how many bytes for each filed. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/18
Shuai / Do we really want to repeat ourself about how ASTM define the RID message and size of each field?  The text here explain clearly what ASTM has been defined, not DRIP.
However, If that is preferable, , see the following yellow highlight text.  If not, I suggest we remove the note.

I think the most important information is that *we* at the IETF have been provided a 20 byte limit for the RID by ASTM and other information seems to me mostly informative. I see this information missing in the proposed text which makes me think we may have missed something.

And when F3411-21 is published, we will be squeezed down to 19 bytes.  (the balloting is 'cooked' as anyone that has something to say, said it in the calls that led to the balloted ver).

ID Type 4 will be "Session ID".  Type 3 UUID, although a session id, will remain due to existing implementations.  But IETF will get Specific ID 1 and 3GPP's 1609.2 proposal gets Specific ID 2.

<shuai>
                sure
</shuai>

•      Editor-note 8: is there a need to explain the how binding/proxy/ translation between the HHIT and X509? Should this be addressed in Arch- or solution?  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/20
Shuai/  I don’t think we have reach an agreement where we should we address the binding between HHIT and X509.  The solution draft in https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07 does not even mention the binding between HHIT and X509. If we don’t have a solution for now, I suggest we remove the entire text mentioning the HHIT and X509 binding as follows:

“

<shuai>

works fine to me.

•      Editor-note 9: to be more specific regarding how HHIT can only use as little as 84 bytes to address the crypto concern.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/21
Shuai/  refer to RID-07, https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.5.   Do we need to repeat the same text here in arch-?   If we do, see proposal highlighted text:

“

<shuai>

</shuai>
sounds reasonable -- at least for the next version. If you keep the byte number, please indicate  64 byte corresponds to Ed25519 and is taken as an example.

<shuai>
                Unless we show there is a value to keep the byte number, otherwise let’s leave them out.
</shuai>

•      Editor-note 10: to be more specific why 200 bytes is sufficient. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/22
Shuai/ @Card, Stu<mailto:[email-masked]> I know you have provided text in the Github, please see the following highlighted text. You think add more clarification if required.

“

<shuai>

</shuai>
sounds reasonable.

•      Editor-note 11: Explain how HIT itself and HHIT registry address naming collision.  https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/25
Shuai/ Where should be address this?  It has been explained in https://datatracker.ietf.org/doc/html/rfc7343#appendix-A

<shuai>

                I will remove 11 unless I heard more detailed comments on this.
</shuai>
We do not necessarily say how it deals with collision but we need to said RID design prevents the collision between two registries.
•      Editor-note 14: Good to have: adding match requirement numbering from requirement document https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30
Shuai/ This might be done after we have addressed all the comments in Section 4.

let's see how it shows up in the next version.
4.3.  HHIT for DRIP Identifier Registration and Lookup
•      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/26
•      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27
•      https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/28

Editor-note 12: more description regarding 1) Is that something we should address in the Arch- 2) if yes, then adding more text about how a trustable lookup is performed
Shuai/ I think that is explained in UAS-RID https://datatracker.ietf.org/doc/html/draft-ietf-drip-rid-07#section-3.4
It seems to me that at the architecture level we need to have a clear idea on what type of information will each registry have, how registration happens, and how information are retrieved. This seems essential to me at least to be able to validate the RID. This can be done in the future version.

--
Daniel Migault
Ericsson

--
Daniel Migault
Ericsson