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

["Panwei (William)" <[e-mail]>]

Hi Eric,

Thanks for your reply, please see inline.

Regards & Thanks!
Wei Pan

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

Hi Wei Pan,

From: Panwei (William), August 13, 2020 8:29 AM
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.

<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.

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.

<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.)

I think it's better to change the style of TPM1.2 to the same one of TPM2.0.

<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.

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>.
[Wei] Thanks.

Eric

Regards & Thanks!
Wei Pan