[Drip] Fwd: Re: draft-moskowitz-drip-uas-rid & Cie

[Robert Moskowitz <[e-mail]>]

To the tm-rid list:

I missed that this exchange did not include this list!

So here is the last exchange that includes all of Med's and my content.

Please feel free to add.  I will try and capture any applicable comments 
in -07.


-------- Forwarded Message --------
Subject: 	Re: draft-moskowitz-drip-uas-rid & Cie
Resent-Date: 	Wed, 9 Sep 2020 05:37:26 -0700 (PDT)
Resent-From: 	[e-mail]
Resent-To: 	[e-mail], [e-mail], 
[e-mail], [e-mail]
Date: 	Wed, 9 Sep 2020 08:36:52 -0400
From: 	Robert Moskowitz <[e-mail]>
To: 	[e-mail], [e-mail] 
<[e-mail]>
CC: 	[e-mail] <[e-mail]>, [e-mail] 
<[e-mail]>



Another thought:

I can add another appendix that shows the 84 byte self-claim. That is:

RID + Timestamp + HI + Sig

That takes care of one of the security concerns directly.  Where this 
self-claim is used, is then in various (and drip-auth is only one such) 
protocol documents.

The only concern, here, is what Timestamp to use?  This is very case 
dependent in which protocol the self-claim appears and any Timestamps 
used in said protocol.  So for example, we have already discussed that 
for this claim appearing in the Authentication Message, it SHOULD be the 
same timestamp used elsewhere in the Authentication Message.

If for example, uas-rid gets used for mas-rid (manned aircraft systems), 
there could well be a different timestamp format.

Stay tuned, I will get this out today, barring other interruptions.

Bob

On 9/9/20 8:25 AM, Robert Moskowitz wrote:
>
>
> On 9/9/20 7:28 AM, [e-mail] wrote:
>> Standard
>>
>> Re-,
>>
>> Please see inline.
>>
>> Cheers,
>>
>> Med
>>
>> *De :*Robert Moskowitz [mailto:[e-mail]]
>> *Envoyé :* mercredi 9 septembre 2020 12:20
>> *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>; 
>> [e-mail]
>> *Cc :* [e-mail]; [e-mail]
>> *Objet :* Re: draft-moskowitz-drip-uas-rid & Cie
>>
>> Med,
>>
>> I was surprised that submit not only did not put the doc in a holding 
>> que, but did not even go through the confirm process.
>>
>> [Med] There was something that went wrong. Not going through the 
>> confirm process is normal though if you were connected to the 
>> datatracker when submitting the draft. Nevertheless, the submission 
>> should trigger a message to the chairs for validation, which we 
>> didn’t receive!
>>
>> I believe that draft-moskowitz-drip-uas-rid-06 implemented all the 
>> requested inclusions and changes. This was covered in the Interim 
>> meeting with a request for reviewers to confirm that all the new 
>> appendices are inclusive and if any of them should instead be in the 
>> main part.
>>
>> [Med] I do see that it still depends on the HHIT registries I-D. I’d 
>> like we fix this issue so that we can have the control on the 
>> document, otherwise the document will go ** no where **.
>>
>
> I would like that replaced with a yet to be written EPP draft. It is a 
> problem.  I can remove the HHIT registries and put in a TBD on the EPP 
> draft.  I am letting the HHIT registries draft just expire.
>
>> The only suggestion you made that I did not implement was to also 
>> include Adam's two drafts, or at least 
>> draft-wiethuechter-drip-identity-claims-00
>>
>> [Med] The claims draft builds also on HHIT. We do need some 
>> rationalisation of the documents.
>>
>
> I will mod the claims draft to reference drip-uas-rid.  Also the auth 
> draft.
>
>>
>> My position is that drip-uas-rid defines how the RID is constructed; 
>> I believe I now have that in -06. Separate documents will then 
>> actually cover the DRIP protocols that use it.
>>
>> [Med] Hmm. Defining the RID without defining how it will be used 
>> would not be the approach I’d recommend. I hope that both the 
>> attributes and their usage is in the scope and defined in one singe 
>> document. The same comment apply for the claims I-D.
>>
>
> Well it does define its use in the ASTM Basic Message as Type 4.
>
> My concern, going forward is that there are different discussions on 
> what to get 'right' for both, and one can hold up the other.  
> drip-auth and drip-identity-claims meet items in drip-req, but I do 
> not see them as blockers for drip-uas-rid.
>
>>
>> So I hold that -06 is ready for workgroup adoption.
>>
>> [Med] -07 should be submitted as -06 is “dead”. I hope that the 
>> pending issues will be fixed in -07 so that we can issue a WG call 
>> for adoption. The token is yours :-)
>>
>
> I will submit a -07, removing the reference to hhit-registry and 
> putting a TBD on EPP registration.
>
> The definition of uas-rid should not be dependent on the registration 
> mechanism.  It is needed per drip-req, but not a blocker on uas-rid.
>
>> Yes, it is not ready for last call, but it SHOULD be close...
>>
>> Bob
>>
>> On 9/9/20 3:40 AM, [e-mail] 
>> <mailto:[e-mail]> wrote:
>>
>>     Hi Bob, all,
>>
>>     I was recently on vacation and I’m starting catching up on drip
>>     matters.
>>
>>     Can you please confirm/infirm whether the proposal below was
>>     implemented in the rid draft?
>>
>>     As it seems there was a “bug” in the submission of the uas-rid
>>     draft, can you please re-submit it as an ** individual submission
>>     **. Thanks.
>>
>>     As soon as we check that the proposed plan (see below) is
>>     implemented and the individual I-D is active again, Daniel and
>>     myself will consider issuing a call for adoption.
>>
>>     Cheers,
>>
>>     Med
>>
>>     *De :*Robert Moskowitz [mailto:[e-mail]]
>>     *Envoyé :* mercredi 5 août 2020 12:01
>>     *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>>     <mailto:[e-mail]>;
>>     [e-mail]
>>     <mailto:[e-mail]>
>>     *Cc :* [e-mail] <mailto:[e-mail]>
>>     *Objet :* Re: draft-moskowitz-drip-uas-rid & Cie
>>
>>     Med,
>>
>>     Back in the beginning it was all one doc.  But there were
>>     comments about "well really this should be separated".  So I am
>>     not adverse to bringing it all back together...
>>
>>     Bob
>>
>>     On 8/5/20 5:14 AM, [e-mail]
>>     <mailto:[e-mail]> wrote:
>>
>>         Hi Bob, all,
>>
>>         As discussed during the IETF#108 meeting, the plan is to
>>         include slots to discuss solutions in the forthcoming
>>         interims. To that aim, it would be helpful to prepare the
>>         documents to be ready for the WG to consider their adoption.
>>
>>         With that in mind, and putting aside technical details for
>>         the moment, I re-read draft-moskowitz-drip-uas-rid with a
>>         focus on the structure and practicalities to have a document
>>         that is not too much dependent on others.
>>
>>         Even if the document does not list drafts as Normative
>>         references,  *** at least three individual I-Ds HAVE to be
>>         listed as Normative *** (see my attached comments). This
>>         suboptimal and won’t help progressing the document. We need
>>         to avoid that as much as we can.
>>
>>         My take is to “group” all these pieces in
>>         draft-moskowitz-drip-uas-rid rather than having many pieces
>>         of the puzzle in separate documents. Once we have his common
>>         document, we will need to coordinate with other relevant WGs
>>         to progress the document: e.g., inform them that we are
>>         planning to adopt, send formal review requests, WGLCs, etc.
>>
>>         Some extensions may be used beyond RID, but this is something
>>         that can be mentioned explicitly in the common document.
>>         That’s said the details how the extension(s) will apply
>>         should be left out of the scope of the common document.
>>
>>         Comments are more than welcome, as usual.
>>
>>         Cheers,
>>
>>         Med
>>
>>     _________________________________________________________________________________________________________________________
>>
>> -- 
>> Robert Moskowitz
>> Owner
>> HTT Consulting
>> C:248-219-2059
>> F:248-968-2824
>> E:[e-mail] <mailto:[e-mail]>
>>
>> There's no limit to what can be accomplished if it doesn't matter who 
>> gets the credit
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.