Subject: [Rats] Which Asymmetric algorithms for Charra?

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 11 Aug 2020 22:51:47 +0000

During the charra presentation at IETF 108, we said we were going to ask the
following question to the list: "Should the algorithm set defined in YANG be
reduced to just those asymmetric algorithms currently exposed in the current
TPM 1.2 and 2 specifications?"

This is reflected seen in
https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-upd
ate-00, Slide 7.

The proposal I would like to make is as follows:

*	The TCG tracked algorithms supportable by a TPM should be the only
ones included in a charra maintained list of YANG identities.   

*	This identity set needs to be extendable to new algorithms for any
YANG models which augment charra.

*	TCG Algorithm Registry Revision 01.32, Table 3 at
https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry
_r1p32_pub.pdf contains the algorithms we should encode.

*	There are other types of information within this table, and we might
as well encode the full table within a YANG model.   That way we can
explicitly make the scope of a "ietf-tcg-algs.yang" model the contents this
TCG table encoded in YANG.

*	The YANG model will indicate what TCG algorithms are deprecated by
the IETF.  However identities for these deprecated algorithms from the TCG
table will be assigned.  (e.g., SHA-1)

Are there any objections/questions/comments on this proposal?    I have a
strawman YANG file posted at:

https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:
patch-4

Henk also is thinking of encoding this same Table information within CDDL.
That could be inserted as an additional informational element of the
document for where people prefer CDDL.

Eric

Eric Voit 

Principal Engineer

.:|:.:|:. Cisco Systems, Inc.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Aug 2020 19:26:53 -0400

> TPM 1.2 and 2 specifications?"

You are asking about *asymmetric* algoritms.
I'd like to see EdDSA in the list, and I suspect that they aren't in the TPM spec.

    > https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-upd

And that slide shows them missing.

    > ones included in a charra maintained list of YANG identities.

You also write:
   2. Identities instead of strings for TCG and IETF crypto algorithm types.
      Strings allow lots of errors to be introduced. (Question #1)

the otherside if you don't use strings is you use an enum, which is not an
IANA registry.  So you need an integer with an IANA registry.

    > table will be assigned.  (e.g., SHA-1)

Good.

    > https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:

I think you need determine if this is a *TCG TPM* yang module, or if it is
intended to accomodate other technologies.  They might be essentially
proprietary, but for this interface, makes them interoperate.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 12 Aug 2020 00:17:35 +0000

Hi Michael,

> From: Michael Richardson, August 11, 2020 7:27 PM
> 
>     > During the charra presentation at IETF 108, we said we were going to
ask
> the

The intent of charra is to be TPM specific.  So for charra it seems to make
sense to only include only asymmetric algorithms which can be served from
TPM chips.  I.e., Non TCG algorithms don't seem standardizable for this
role.

The good news is that the proposed model has been structured to allow the
addition of new algorithms by TCG or other non-standard entities who wish to
take on new algorithms.  This can be done by simply defining a new algorithm
which imports and extends the YANG identity set currently defined.
 
>     > This is reflected seen in
https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-
> upd
IANA
> registry.  So you need an integer with an IANA registry.

I initially had used ENUMs.  But ENUMs in YANG are hard to extend with new
values, this is why I moved to YANG identities.   Otherwise than that
identities should effectively give the same result as YANG models are
registered with IANA.
 
> proprietary, but for this interface, makes them interoperate.

Exactly.  During IETF 108, the file integrated TCG and IETF values.  Since
TPMs can't really handle IETF values, I rescoped and renamed to be only TCG
algs (i.e., "ietf-tcg-algs.yang") in this proposal.

Eric

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 12 Aug 2020 07:58:43 +0000

Hi Eric,

Generally, I'm fine with your proposal. I have only one question below.

The TCG_Algorithm_Registry_r1p32_pub defines a variety of SHA algorithms named with key length as a suffix, it also defines the ID values for the different curves used for elliptic curve cryptography. But it seems like that the TCG_Algorithm_Registry_r1p32_pub doesn't specify the key length of the RSA algorithm. So do we need to define fine-granular RSA algorithms in the YANG module?

Regards & Thanks!
Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
To: [email-masked]
Subject: [Rats] Which Asymmetric algorithms for Charra?

During the charra presentation at IETF 108, we said we were going to ask the following question to the list: "Should the algorithm set defined in YANG be reduced to just those asymmetric algorithms currently exposed in the current TPM 1.2 and 2 specifications?"

This is reflected seen in https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-update-00, Slide 7.

  *   The TCG tracked algorithms supportable by a TPM should be the only ones included in a charra maintained list of YANG identities.

     *   This identity set needs to be extendable to new algorithms for any YANG models which augment charra.

  *   TCG Algorithm Registry Revision 01.32, Table 3 at https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf contains the algorithms we should encode.

     *   There are other types of information within this table, and we might as well encode the full table within a YANG model.   That way we can explicitly make the scope of a "ietf-tcg-algs.yang" model the contents this TCG table encoded in YANG.

  *   The YANG model will indicate what TCG algorithms are deprecated by the IETF.  However identities for these deprecated algorithms from the TCG table will be assigned.  (e.g., SHA-1)

Are there any objections/questions/comments on this proposal?    I have a strawman YANG file posted at:
https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:patch-4<https://github.com/ietf-rats-wg/basic-yang-module/compare/master....ericvoit:patch-4>

Henk also is thinking of encoding this same Table information within CDDL.  That could be inserted as an additional informational element of the document for where people prefer CDDL.

Eric

Eric Voit
Principal Engineer

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 12 Aug 2020 19:20:28 +0000

Hi Wei Pan,

I don't think we need to define a key length for RSA.  

*	None of our RPCs are involved with generating a new key.  And we can
always discover the length of the key by referencing the information from
the keystore using known information (e.g., the certificate-name). 
*	Looking at the various SHA algorithms, they are actually different
algorithms (since they produce different digest sizes).
*	If we just match to what is in the TCG spec, we don't have to
define/defend a different scoping than they have already made.

Thanks,

Eric

From: RATS <[email-masked]> On Behalf Of Panwei (William)
Sent: Wednesday, August 12, 2020 3:59 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?

Hi Eric,

The TCG_Algorithm_Registry_r1p32_pub defines a variety of SHA algorithms
named with key length as a suffix, it also defines the ID values for the
different curves used for elliptic curve cryptography. But it seems like
that the TCG_Algorithm_Registry_r1p32_pub doesn't specify the key length of
the RSA algorithm. So do we need to define fine-granular RSA algorithms in
the YANG module?

Regards & Thanks!

Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Rats] Which Asymmetric algorithms for Charra?

https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:
patch-4
<https://github.com/ietf-rats-wg/basic-yang-module/compare/master....ericvoi
t:patch-4> 

Eric

Eric Voit 

Principal Engineer

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 26 Aug 2020 01:37:05 +0000

Hi Eric,

Got it. Now I have no questions.

Regards & Thanks!
Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, August 13, 2020 3:20 AM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?

Hi Wei Pan,

  *   None of our RPCs are involved with generating a new key.  And we can always discover the length of the key by referencing the information from the keystore using known information (e.g., the certificate-name).
  *   Looking at the various SHA algorithms, they are actually different algorithms (since they produce different digest sizes).
  *   If we just match to what is in the TCG spec, we don't have to define/defend a different scoping than they have already made.

Thanks,
Eric

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Panwei (William)
Sent: Wednesday, August 12, 2020 3:59 AM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Which Asymmetric algorithms for Charra?

Hi Eric,

Regards & Thanks!
Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 12, 2020 6:52 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rats] Which Asymmetric algorithms for Charra?

Are there any objections/questions/comments on this proposal?    I have a strawman YANG file posted at:
https://github.com/ietf-rats-wg/basic-yang-module/compare/master...ericvoit:patch-4<https://github.com/ietf-rats-wg/basic-yang-module/compare/master.....ericvoit:patch-4>

Eric

Eric Voit
Principal Engineer