[Anima] My comments about draft-richardson-anima-voucher-delegation-00:

["Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]>]

Hi Michael,
This is an interesting draft, please see my comments as below:


pg 2:

   o  while the use of a nonceless voucher (see {{RFC8366} section 4)

      can permit the MASA to be offline, it still requires the public

      key/certificate of the Registrar to be known at issuing time



comment:

      don't think it as one disadvantage of the BRSKI. As even for the DASA

      solution, the public key of the registrar are still required to be

      known at issuing time. At least, this sentence has not clarified the

      real problem clearly.



pg 2:

   o  the MASA must also approve all transfers of ownership, impacting

      the rights of the initial seller to transfer ownership as they see

      fit.



comment:

      here, the initial seller seems not very accurate. Who is the initial

      seller? Actually, the term of "any re-seller/distributer" are more

      accurate here.



pg 2:

   o  if the Registrar has any nonceless vouchers, then it can not

      change it's public key, nor can it change which certification

      authority it uses



comment:

      How can the DASA address this problem?



pg 2:

   o  the creator of an assembly of parts/components can speak for the

      entire assembly of parts in a transparent way



comment:

      the creator means the vendor?





pg 2:

1.1.1.  Disconnected or Offline MASA



   A Registrar wishes to onboard devices while not being connected to

   the Internet.



comment:

      how to achieve this goal? by pro-provisioning the related delegation

      vouchers to the device?



pg 2:

1.1.2.  Resale of devices



   An owner of a device wishes to resale devices which have previously

   been onboarded to a third party without specific authorization from

   the manufacturer.



comment:

   Does the resoled devices have to be onboarded before?



pg 3:

   assembly



comment:

   assembly means?



pg 3:

   The sub-components of the assembly needs

   to communicate with other sub-components, and so all the parts need

   to transparently onboarded.



comment:  clarification requested.



pg 3:

   This delegation can potentially be repeated multiple times to enable

   second, third, or n-th level of resale.



comment:

    So, there should be 0..n intermediate vouchers and only one end voucher in the device. right?



pg 3:

   The delegation voucher pins the identity of the delegated authority

   using a variety of different mechanisms which are covered in

   Section 7.



comment:

   why do we need a variety of different mechanisms?

   Is one mechanism defined in this draft not enough?



pg 5:

   Delegation Voucher:  a Delegation Voucher is an [RFC8366] format

      voucher that has additional fields to provide detailed the entity

      to which authority has been delegated.



comment:

   nit: to provide details of the entity...

   We need a very clear relation description among the 3 kinds of voucher:

   delegation voucher, intermediate voucher and end voucher. Leave it to the

   later discussion!



pg 5:

   Intermediate Voucher:  a voucher that is not the final voucher

      linking a pledge to its owner.



comment:

   Does intermediate voucher equal to the delegated voucher? I think so.



pg 5:

   End Voucher:  a voucher that is the final voucher linking a pledge to

      its owner.



comment:

   Does end voucher equal to the normal voucher? I think so.





pg 5:

   There are a few new fields: pinned-delegation-certificate-authority,

   pinned-delegation-name, delegation-count.



comment:

   we need the definition of this new fields, not only in the description of the yang model, I think.

   and some nits: countdown, miss delegation-voucher and

   intermediate-identities.



pg 7:

   leaf pinned-certificate-authority {



comment:

   How does the upper-layer MASA/DASA know the pinned-certificate-authority

   which will delegtate out?



pg 7:

   leaf delegation-voucher {



comment:

   a chain of delegation-vouchers on the delegation path? or a nested voucher structure?

   And the voucher is a CMS structure with signature, right?

   if there is delegation information, it should be in this

   delegation-voucher field. And for the MASA created voucher, it should not

   include the delegation-voucher, since it is the up-most entity in the

   supply chain and no other entity can delegate the authority to it, right?

   How about the new DASA URL?



pg 8:

           leaf delegation-countdown {

             type int16;

             description

             "Number of delegations still available. If zero

              or omitted, then this is a terminal voucher and

              may not be further delegated";



comment:

  terminal voucher is not end voucher!

  It should be the initial voucher created by the MASA and does not include

  delegation-voucher field, right?

  Furthermore, it seems that the countdown field is redundant with the

  delegation-voucher.



pg 8:

   <CODE ENDS>



comment:

  Who sign the end voucher?

  Can the intermediate voucher independently exist?



pg 8:

3.3.  Delegation of multiple devices



   A MASA MAY delegate multiple devices to the same Registrar by putting

   an array of items in the "serial-number" attributes.  (XXX-how to

   describe this in the YANG)



comment:

   What is the use case? Current BRSKI does not support this, but should?



pg 8:

   A pledge which has previously stored a delegation voucher and

   delegated authority, SHOULD include it in its voucher request.  This

   will be in the form of a certificate provided by the "previous"

   owner.



comment:

   include it = include the delegation voucher?

   I still think that a delegation voucher can not really exist as an

   instance, it's actually an end voucher including a series of intermediate

   vouchers in itself.



pg 9:

   A certificate from the set of intermediate-identities is

   expected to validate the signature on this zeroth end-entity voucher.

   (XXX- This attribute can be replaced by the CMS certificate chain)



comment:

   The intermediate-identities list should have the same order with the

   intermediate voucher chain backwards along the delegation path to the

   MASA.

   In last sentence, it said that the zero voucher has not been signed. Here,

   how to validate its signature? Why is the regarding certificate expected

   to validate the zero voucher?



pg 9:

   working set of trust anchors.



comment:

   So, the pledge has multiple trust anchors possibly.

   So, the next question is how does the pledge or the registrar know which

   trust anchor to choose for next onboarding procedure?


B.R.
Frank


This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!