Subject: [Rats] pub-key-id or certificate-name (was RE: Some new comments for CHARRA YANG module)

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

Hi Shwetha, Panwei, and other Charra authors,

On another parallel but related question, should we use <certificate-name>
rather than <pub-key-id> in the RPC inputs below?   Either choice is *only*
required when a subset of TPMs are being quoted, or keys from something
other than a default AIK are desired.

The reason I think this might be good is that the current charra model has
the following elements in the data nodes:

    +--rw rats-support-structures

       +--rw tpms* [tpm-name]

          +--rw tpm-name                     string

          +--rw certificates

             +--rw certificate* [certificate-name]

                +--rw certificate-name    string

                +--rw certificate-ref?    leafref

With <certificate-name> you directly know the TPM.  With some <pub-key-id>,
you will need to go externally to:

   module: ietf-keystore

     +--rw keystore

        +--rw asymmetric-keys

           +--rw asymmetric-key* [name]

              +--rw name                                    string

              +--rw public-key                              binary

and do some conversions to match the RPC's <pub-key-id> (binary) to  <name>
(string).  With <name> you would get the list of certificates, and then use
those to find the proper TPM  (which seems complex and unnecessary). Plus
you will still need to determine the proper the <certificate-name> for the
RPC output anyway.     I would guess that implementers and YANG doctors are
likely to complain.

Thoughts?

Eric

From: Eric Voit (evoit) 
Sent: Friday, August 14, 2020 3:26 PM
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,

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] <mailto:[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