Subject: Re: [Rats] Review of draft-birkholz-rats-daa

From: Christopher Newton <[email-masked]>
Date: Sun, 6 Jun 2021 20:12:37 +0000

Hi Thomas,

Thank you for your comments.

> Is it really necessary to introduce the new "DAA Issuer" role?
> 
> It seems to me that if the JOIN and SIGN phases are considered as two separate attestation protocols, the Issuer could be mapped to a couple of well-known RATS roles depending on the phase it is involved in:
> * Verifier for JOIN - plus an authorisation RP on top that grants the group credentials to the authenticated Attester;
> * Endorser for SIGN.

Yes, the DAA Issuer is a separate role. it is effectively a Certificate Authority for the DAA keys. The difference from a PKI CA is that the Verifier uses the public key of the DAA Issuer to directly verify the DAA signature. The signer's public key is not available to the verifier.

For a TPM, the Endorser is the chip manufacturer who provides a PKI certificate for the TPM's endorsement key. However, the endorsement key cannot be used as a DAA key as it is an encryption key. it is only used to enable the DAA Issuer to authenticate the TPM in a deniable way. After the Issuer authenticates the TPM it provides a DAA credential to the DAA signing key. The Endorser can take on the role of the DAA Issuer, but this is not a requirement. 

We hope that this makes things a little clearer, we could add more detail in the RATS DAA document if this would help.

Regards,

Chris and Liqun.

--
Dr Christopher Newton
Surrey Centre for Cyber Security
Department of Computer Science
University of Surrey
Guildford, Surrey, GU2 7XH, UK
--

-----Original Message-----
From: Thomas Fossati <[email-masked]> 
Sent: 26 May 2021 13:04
To: [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: Review of draft-birkholz-rats-daa

Hi RATS-DAA authors,

I have reviewed draft-birkholz-rats-daa-00 and I think this is a useful document, plus it is short and sweet.

I may have a few editorial suggestions, but I'd like to ask one meta question first - apologies if this was brought up in previous
conversations:

Is it really necessary to introduce the new "DAA Issuer" role?

It seems to me that if the JOIN and SIGN phases are considered as two separate attestation protocols, the Issuer could be mapped to a couple of well-known RATS roles depending on the phase it is involved in:
* Verifier for JOIN - plus an authorisation RP on top that grants
  the group credentials to the authenticated Attester;
* Endorser for SIGN.

Cheers, thank you.

t

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 Jun 2021 07:07:27 +0000

Hi Christopher,

I think it would be worthwhile to note in the security considerations section that you are making certain assumptions about the content of the token. It is easy to imagine that those using the token get this wrong.
There is also good privacy terminology you can rely on, see https://datatracker.ietf.org/doc/html/rfc6973

Ciao
Hannes

-----Original Message-----
From: Christopher Newton <[email-masked]>
Sent: Sunday, June 6, 2021 10:20 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>; Henk Birkholz <[email-masked]>; Liqun Chen <[email-masked]>; Christopher Newton <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Hi Hannes,

Thank you for your interest and comments.

> In any case, [DAA] has to be a normative reference.
Yes.

> I would also like to see the privacy properties articulated in more detail, particularly when DAA is used with an attestation token that potentially contains a lot of claims.

For DAA itself, we assume that the attestation token does not reveal the identity of the signer. However, if this is the case there is research into property based attestation that will anonymise the attestation token.

Regards,

Liqun and Chris.

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: 26 May 2021 14:59
To: [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Hi Henk,

I have not been following the RATS work closely and hence I was wondering whether this document is supposed to become part of the architecture document?
In any case, [DAA] has to be a normative reference. I would also like to see the privacy properties articulated in more detail, particularly when DAA is used with an attestation token that potentially contains a lot of claims
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 7 Jun 2021 10:08:19 +0000

Hi Chris,

Thank you for your explanation.

What I was trying to say, maybe not very clearly, is that if one
decomposes the DAA protocol into its two constituent phases, there seem
to be no need to add the DAA Issuer as an *explicit* role to the current
list [1].  The DAA Issuer can be expressed as a "meta" role that assumes
the RATS Verifier and RATS Endorser roles depending on context.

cheers, t

[1] https://ietf-rats-wg.github.io/architecture/draft-ietf-rats-architecture.html#name-roles

On 06/06/2021, 21:12, "Christopher Newton" <[email-masked]> wrote:
> > It seems to me that if the JOIN and SIGN phases are considered as
> > two separate attestation protocols, the Issuer could be mapped to a
> > couple of well-known RATS roles depending on the phase it is
> > involved in:
> > * Verifier for JOIN - plus an authorisation RP on top
> >   that grants the group credentials to the authenticated Attester;
> > * Endorser for SIGN.
>
> Yes, the DAA Issuer is a separate role. it is effectively a
> Certificate Authority for the DAA keys. The difference from a PKI CA
> is that the Verifier uses the public key of the DAA Issuer to directly
> verify the DAA signature. The signer's public key is not available to
> the verifier.
>
> For a TPM, the Endorser is the chip manufacturer who provides a PKI
> certificate for the TPM's endorsement key. However, the endorsement
> key cannot be used as a DAA key as it is an encryption key. it is only
> used to enable the DAA Issuer to authenticate the TPM in a deniable
> way. After the Issuer authenticates the TPM it provides a DAA
> credential to the DAA signing key. The Endorser can take on the role
> of the DAA Issuer, but this is not a requirement.
>
> We hope that this makes things a little clearer, we could add more
> detail in the RATS DAA document if this would help.
>
> Regards,
>
> Chris and Liqun.
>
>
> --
> Dr Christopher Newton
> I have reviewed draft-birkholz-rats-daa-00 and I think this is a
> useful document, plus it is short and sweet.
>
> I may have a few editorial suggestions, but I'd like to ask one meta
> question first - apologies if this was brought up in previous
> conversations:
>
> It seems to me that if the JOIN and SIGN phases are considered as two
> separate attestation protocols, the Issuer could be mapped to a couple
> of well-known RATS roles depending on the phase it is involved in:

---

From: Christopher Newton <[email-masked]>
Date: Mon, 7 Jun 2021 19:56:12 +0000

Hi Thomas,

We understand your suggestion now and we accept that the Endorser role can also cover that of a DAA Issuer. We assume that this (expanded Endorser) role, when implemented, could be fulfilled by two entities, for example the manufacturer who would provide the endorsement key for authenticating the attester and a separate entity who would issue the DAA credentials. This is likely to be the case in a real DAA application scenario.

Regards,

Chris and Liqun.

-----Original Message-----
From: Thomas Fossati <[email-masked]> 
Sent: 07 June 2021 11:08
To: Newton, Christopher Dr (Computer Science) <[email-masked]>; [email-masked]
Cc: Henk Birkholz <[email-masked]>; [email-masked]; Chen, Liqun Prof (Computer Science) <[email-masked]>; Thomas Fossati <[email-masked]>
Subject: Re: Review of draft-birkholz-rats-daa

Hi Chris,

What I was trying to say, maybe not very clearly, is that if one decomposes the DAA protocol into its two constituent phases, there seem to be no need to add the DAA Issuer as an *explicit* role to the current list [1].  The DAA Issuer can be expressed as a "meta" role that assumes the RATS Verifier and RATS Endorser roles depending on context.

cheers, t

[1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf-rats-wg.github.io%2Farchitecture%2Fdraft-ietf-rats-architecture.html%23name-roles&amp;data=04%7C01%7Cc.newton%40surrey.ac.uk%7C74428f0552fe454aeba308d9299c3618%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637586573164417513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&amp;sdata=IXFU%2FJmDrYrQdCOWVNsiGq%2BjYWiV03kcr276oaIYjyc%3D&amp;reserved=0

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 7 Jun 2021 20:36:00 +0000

Hi Chris,

On 07/06/2021, 21:00, "Christopher Newton" <[email-masked]> wrote:
> This is a good idea, but how do we get access to edit the security
> considerations section to add some comments? We are both new to IETF
> standards and how they are developed and updated.

If you have a github account already, ask Henk to add you as a
collaborator to the repo [1].

The source file is markdown -- with a few tweaks, see [2] for some
documentation.

You need a couple of tools to compile locally: the kramdown-rfc2629
suite [3] and a recent GNU make.

(The CI that is already set up for the repo should do the work for
you when you send a PR or update an "origin" branch, so in principle you
could avoid the step above if you really really wanted to.)

In case you are stuck, reach out and we will try to unblock you.

Have fun!

[1] https://github.com/ietf-rats/draft-birkholz-rats-daa
[2] https://github.com/cabo/kramdown-rfc2629
[3] https://github.com/cabo/kramdown-rfc2629#usage

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Jun 2021 06:18:55 +0000

Hi Chris,

You are the authors of the draft and you can put in there whatever you want. When it is an individual draft then you can do whatever you want.
Once it becomes a working group document the group decides what goes into the document...

Ciao
Hannes

-----Original Message-----
From: Christopher Newton <[email-masked]>
Sent: Monday, June 7, 2021 10:01 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>; Henk Birkholz <[email-masked]>; Liqun Chen <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Dear Hannes,

This is a good idea, but how do we get access to edit the security considerations section to add some comments? We are both new to IETF standards and how they are developed and updated.

Regards,

Chris and Liqun.

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: 07 June 2021 08:07
To: Newton, Christopher Dr (Computer Science) <[email-masked]>; [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>; Henk Birkholz <[email-masked]>; Chen, Liqun Prof (Computer Science) <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Hi Christopher,

I think it would be worthwhile to note in the security considerations section that you are making certain assumptions about the content of the token. It is easy to imagine that those using the token get this wrong.
There is also good privacy terminology you can rely on, see https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc6973&amp;data=04%7C01%7Cc.newton%40surrey.ac.uk%7C206268f908b0426f080c08d92982f12e%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637586464708416857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Yz2r4hPaY%2Ft0J03wSVvwCz5X1bw5loCvrVsmemDwFMY%3D&amp;reserved=0

Ciao
Hannes

-----Original Message-----
From: Christopher Newton <[email-masked]>
Sent: Sunday, June 6, 2021 10:20 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>; Henk Birkholz <[email-masked]>; Liqun Chen <[email-masked]>; Christopher Newton <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Hi Hannes,

Yes.

Regards,

Liqun and Chris.

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: 26 May 2021 14:59
To: [email-masked]
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: RE: Review of draft-birkholz-rats-daa

Hi Henk,

I have not been following the RATS work closely and hence I was wondering whether this document is supposed to become part of the architecture document?
In any case, [DAA] has to be a normative reference. I would also like to see the privacy properties articulated in more detail, particularly when DAA is used with an attestation token that potentially contains a lot of claims IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.