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

["Eric Voit (evoit)" <[e-mail]>]

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.

 

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?

 

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