Subject: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 14 Aug 2020 19:25:49 +0000

Hi Wei Pan,

Just slightly related to the question you asked previously, I have a
question on the model/tree you sent back (in-line...)

> From: Panwei, August 14, 2020 6:01 AM

> To: Eric Voit (evoit) <[email-masked]>; Shwetha Bhandari (shwethab)

> Hi Eric,

> Thanks for your reply, please see inline.

> Regards & Thanks!

> Wei Pan

> From: Eric Voit (evoit) [ <mailto:[email-masked]> mailto:[email-masked]]

> Sent: Thursday, August 13, 2020 10:32 PM

> To: Panwei (William) < <mailto:[email-masked]>
[email-masked]>; Shwetha Bhandari

> (shwethab) < <mailto:[email-masked]> [email-masked]>

> Cc:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]>
[email-masked]

> Subject: RE: Some new comments for CHARRA YANG module

> Hi Wei Pan,

> From: Panwei (William), August 13, 2020 8:29 AM Hi Eric,

> 2. The styles of challenge input for TPM1.2 and TPM2.0 are different.

>       +---x tpm20-challenge-response-attestation {TPM20}?

>       |  +---w input

>       |  |  +---w tpm20-attestation-challenge

>       |  |     +---w nonce-value          binary

>       |  |     +---w challenge-objects* []

>       |  |        +---w pcr-list* [TPM2_Algo]

>       |  |        |  +---w TPM2_Algo        identityref

>       |  |        |  +---w pcr-index*       tpm:pcr

>       |  |        +---w TPM2_Algo?          identityref

>       |  |        +---w (key-identifier)?

>       |  |        |  +--:(public-key)

>       |  |        |  |  +---w pub-key-id?   binary

>       |  |        |  +--:(uuid)

>       |  |        |     +---w uuid-value?   binary

>       |  |        +---w tpm-name*           string

> In the TPM2.0 challenge input, the nonce is put aside and the
challenge-objects

> is a list. So you can challenge for different pcr-lists of different TPMs
in one

> challenge input.

>       +---x tpm12-challenge-response-attestation {TPM12}?

>       |  +---w input

>       |  |  +---w tpm1-attestation-challenge

>       |  |     +---w pcr-index*              pcr

>       |  |     +---w nonce-value             binary

>       |  |     +---w TPM12_Algo?             identityref

>       |  |     +---w (key-identifier)?

>       |  |     |  +--:(public-key)

>       |  |     |  |  +---w pub-key-id?       binary

>       |  |     |  +--:(TSS_UUID)

>       |  |     |     +---w TSS_UUID-value

>       |  |     |        +---w ulTimeLow?       uint32

>       |  |     |        +---w usTimeMid?       uint16

>       |  |     |        +---w usTimeHigh?      uint16

>       |  |     |        +---w bClockSeqHigh?   uint8

>       |  |     |        +---w bClockSeqLow?    uint8

>       |  |     |        +---w rgbNode*         uint8

UUID is represented differently in the TPM1.2 and TPM2 models.   In fact in
the TPM1.2 modeling has the UUID broken into constituent parts, none of
which are mandatory where other UUID parts exist.  Shwetha told me that the
UUID structures originally came from Huawei.    A few questions:

(1) UUID only appears in RPCs.  It doesn't appear in the datanodes.   Nor
does UUID appear in draft-ietf-netconf-keystore.  As a result it is hard to
see how it might correspond to a key, at least in an IETF YANG ecosystem.
Is support for UUID really essential?   Why?

(2) Assuming you really want UUIDs, I am hoping the datatypes can be
reconciled between TPM1.2 and TPM2 RPCs.    Is there reason you wouldn't
just use the uuid YANG typedef of RFC6991 for both?

(3) Assuming you really want UUIDs, you need to propose how a UUID might
relate to keys within the IETF ecosystem of YANG models.  

BTW: If you don't need UUIDs, we could always drop them from the model.
(Leaving them to vendor specific augmentations if necessary.)

Thanks,

Eric

>       |  |     +---w add-version?            boolean

>       |  |     +---w tpm-name*               string

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 14 Aug 2020 13:40:18 -0700

I would suggest avoiding UUIDs if possible. Nowadays good RNGs are available and you can just use them to generate a nonce or such. Good RNGs were not available commonly in CPUs when UUIDs were invented, but they are now.  If you just want a nonce, then the internal structure of a UUID is of no value and just adds complexity and confusion.

LL

> On Aug 14, 2020, at 12:25 PM, Eric Voit (evoit) <evoit=[email-masked]> wrote:
> 
> Hi Wei Pan,
>  
> Just slightly related to the question you asked previously, I have a question on the model/tree you sent back (in-line...)
>  
> > To: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>>; Shwetha Bhandari (shwethab)
> >
> > Hi Eric,
> >
> > From: Eric Voit (evoit) [mailto:[email-masked] <mailto:[email-masked]>]
> > To: Panwei (William) <[email-masked] <mailto:[email-masked]>>; Shwetha Bhandari
> > (shwethab) <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > In the TPM2.0 challenge input, the nonce is put aside and the challenge-objects
> > is a list. So you can challenge for different pcr-lists of different TPMs in one
> > challenge input.
> UUID is represented differently in the TPM1.2 and TPM2 models.   In fact in the TPM1.2 modeling has the UUID broken into constituent parts, none of which are mandatory where other UUID parts exist.  Shwetha told me that the UUID structures originally came from Huawei.    A few questions:
>  
> (1) UUID only appears in RPCs.  It doesn't appear in the datanodes.   Nor does UUID appear in draft-ietf-netconf-keystore.  As a result it is hard to see how it might correspond to a key, at least in an IETF YANG ecosystem.  Is support for UUID really essential?   Why?
>  
> (2) Assuming you really want UUIDs, I am hoping the datatypes can be reconciled between TPM1.2 and TPM2 RPCs.    Is there reason you wouldn't just use the uuid YANG typedef of RFC6991 for both?
>  
> (3) Assuming you really want UUIDs, you need to propose how a UUID might relate to keys within the IETF ecosystem of YANG models.  
>  
> BTW: If you don't need UUIDs, we could always drop them from the model.  (Leaving them to vendor specific augmentations if necessary.)
>  
> Thanks,
> Eric
>  
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 Aug 2020 21:00:54 +0000

*   I would suggest avoiding UUIDs if possible. Nowadays good RNGs are available and you can just use them to generate a nonce or such. Good RNGs were not available commonly in CPUs when UUIDs were invented, but they are now.  If you just want a nonce, then the internal structure of a UUID is of no value and just adds complexity and confusion.

As the lead author of the UUID RFC: I agree.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 17 Aug 2020 16:40:05 +0000

I am happy to get rid of it.    I am just making sure that there are no 
objections from the requesting source(s).

Eric

From: RATS <[email-masked]> On Behalf Of Salz, Rich
Sent: Friday, August 14, 2020 5:01 PM
To: Laurence Lundblade <[email-masked]>; Eric Voit (evoit) 
<evoit=[email-masked]>
Cc: [email-masked]; Panwei (William) <[email-masked]>; Shwetha 
Bhandari (shwethab) <[email-masked]>; 
[email-masked]
Subject: Re: [Rats] Orthogonal: UUID? (was RE: Some new comments for CHARRA 
YANG module)

*	I would suggest avoiding UUIDs if possible. Nowadays good RNGs are available 
and you can just use them to generate a nonce or such. Good RNGs were not 
available commonly in CPUs when UUIDs were invented, but they are now.  If you 
just want a nonce, then the internal structure of a UUID is of no value and 
just adds complexity and confusion.

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 18 Aug 2020 08:35:25 +0000

Hi Eric,

Thanks for asking, but I'm afraid that the UUID structures weren't introduced by us Huawei. And we don't use UUIDs, so we don't object to drop them from the model.

Regards & Thanks!

Wei Pan

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Saturday, August 15, 2020 3:26 AM
To: Panwei (William) <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG module)

Hi Wei Pan,

> To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari (shwethab)

> From: Eric Voit (evoit) [mailto:[email-masked]]

> To: Panwei (William) <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari

> (shwethab) <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Thanks,

Eric

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Aug 2020 14:07:28 +0200

Hi all,

the use of UUIDs originates from the early days of module design (pre 
individual -00 I-D), I think. The only reason this usage exists is... 
because that is the only uniform method to identify both a legacy TPM 
1.2 and a TPM 2.0 via the TSS. That is not a very good stand-alone 
reason :-)

To make sure, I'll add two fellow colleagues as CC - just to be on the 
safe side.

Viele Grüße,

Henk

On 18.08.20 10:35, Panwei (William) wrote:
> Hi Eric,
> 
> Thanks for asking, but I’m afraid that the UUID structures weren’t 
> introduced by us Huawei. And we don’t use UUIDs, so we don’t object to 
> drop them from the model.
> 
> Regards & Thanks!
> 
> Wei Pan
> 
> *From:*Eric Voit (evoit) [mailto:[email-masked]]
> *Sent:* Saturday, August 15, 2020 3:26 AM
> *To:* Panwei (William) <[email-masked]>; Shwetha Bhandari 
> (shwethab) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Orthogonal: UUID? (was RE: Some new comments for CHARRA YANG 
> module)
> 
> Hi Wei Pan,
> 
>> Cc: [email-masked] <mailto:[email-masked]>; 
> UUID is represented differently in the TPM1.2 and TPM2 models.   In fact 
> in the TPM1.2 modeling has the UUID broken into constituent parts, none 
> of which are mandatory where other UUID parts exist.  Shwetha told me 
> that the UUID structures originally came from Huawei.    A few questions:
> 
> (1) UUID only appears in RPCs.  It doesn't appear in the datanodes.   
> Nor does UUID appear in draft-ietf-netconf-keystore.  As a result it is 
> hard to see how it might correspond to a key, at least in an IETF YANG 
> ecosystem.  Is support for UUID really essential?   Why?
>