Subject: [Rats] Some new comments for CHARRA YANG module

From: "Panwei (William)" <[email-masked]>
Date: Thu, 13 Aug 2020 12:28:41 +0000

Hi Eric,

In modifying the YANG module, I have some new comments about the module.
1. Do we still need the basic-trust-establishment now? It provides the function of retrieving the certificates of TPM2.0. But I think now the certificates can be get from the rats-support-structure and ietf-keystore.
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
      |  |     +---w add-version?            boolean
      |  |     +---w tpm-name*               string
In the TPM1.2 challenge input, if you want to challenge for different pcr-indexs of different TPMs, you need to construct multiple challenge inputs with different nonce values.
I think it's better to change the style of TPM1.2 to the same one of TPM2.0.
3. In the log-retrieval part, the input uses tpm-name as the identifier, but the output uses certificate-name. The certificate-name isn't used in the log-result, should we also use tpm-name as the identifier of output?

Regards & Thanks!
Wei Pan

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 13 Aug 2020 14:32:26 +0000

Hi Wei Pan,

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

Hi Eric,

1. Do we still need the basic-trust-establishment now? It provides the
function of retrieving the certificates of TPM2.0. But I think now the
certificates can be get from the rats-support-structure and ietf-keystore.

<eric> I can go either way on this.   This RPC could provide some
simplifications for TPMs.  Adding Shwetha to the thread to see if there is
sufficient differentiation from draft-ietf-netconf-keystore-17 (and its
extended family of documents) to justify this RFC.

      |  +---w input

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

      |  |        |  +--:(uuid)

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.

      |  +---w input

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

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

      |  |     |  +--:(TSS_UUID)

In the TPM1.2 challenge input, if you want to challenge for different
pcr-indexs of different TPMs, you need to construct multiple challenge
inputs with different nonce values.

<eric>  This is true.  The question I have is for multiple TPM1.2 line
cards, whether you ever would really need to have a single query which hits
different PCRs.  If yes, then we need the flexibility you are asking.  If
no, the restrictions will simplify the code needed to handle the RPC.  (Note
that for TPM2.0 we already need the extra complexity as groups of PCRs are
hashed together.)

<eric>  If you or others have a business need to have a single query which
targets different PCRs from different line cards, I would agree.  Do you
really have this?  If yes (or even no), are you willing to create some more
XPATH statements which can limit the options so that the exposure of this
flexibility doesn't drive code developers to supporting unneeded variants?

3. In the log-retrieval part, the input uses tpm-name as the identifier, but
the output uses certificate-name. The certificate-name isn't used in the
log-result, should we also use tpm-name as the identifier of output?

<eric> My initial thinking was that perhaps a certificate upgrade has
occurred between the last log-retrieval and the current one.  As the
existing RPC would notify with the new certificate-name, this could save a
step.  However the logs are not really tied to a certificate name, so I will
make the change to <tpm-name>.

Eric

Regards & Thanks!

Wei Pan

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 14 Aug 2020 10:01:27 +0000

Hi Eric,

Thanks for your reply, please see inline.

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Thursday, August 13, 2020 10:32 PM
To: Panwei (William) <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Some new comments for CHARRA YANG module

Hi Wei Pan,

<eric> I can go either way on this.   This RPC could provide some simplifications for TPMs.  Adding Shwetha to the thread to see if there is sufficient differentiation from draft-ietf-netconf-keystore-17 (and its extended family of documents) to justify this RFC.
[Wei] OK. Let's wait for Shwetha's opinions.

<eric>  This is true.  The question I have is for multiple TPM1.2 line cards, whether you ever would really need to have a single query which hits different PCRs.  If yes, then we need the flexibility you are asking.  If no, the restrictions will simplify the code needed to handle the RPC.  (Note that for TPM2.0 we already need the extra complexity as groups of PCRs are hashed together.)

<eric>  If you or others have a business need to have a single query which targets different PCRs from different line cards, I would agree.  Do you really have this?  If yes (or even no), are you willing to create some more XPATH statements which can limit the options so that the exposure of this flexibility doesn't drive code developers to supporting unneeded variants?
[Wei] Actually I have no actual use case for a single query which hits different PCRs. I don't know whether others have. I just raised my point from the perspective of style consistency. But I agree with you that if there is no actual use case the flexibility is useless and a burden. We can keep it the way it is and wait if others have the actual requirement.

<eric> My initial thinking was that perhaps a certificate upgrade has occurred between the last log-retrieval and the current one.  As the existing RPC would notify with the new certificate-name, this could save a step.  However the logs are not really tied to a certificate name, so I will make the change to <tpm-name>.
[Wei] Thanks.

Eric

Regards & Thanks!
Wei Pan