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

From: "Smith, Ned" <[email-masked]>
Date: Mon, 28 Jun 2021 16:14:07 +0000

The TCG has had the notion of a "Privacy CA" for many years, but the ecosystem didn't materialize for Privacy CAs. How is the DAA Issuer different / or otherwise what motivates the ecosystem to be create the DAA Issuer? Given the Endorsements are not privacy preserving, the DAA Issuer would be a central point of possible collusion given it is trusted to preserve privacy? Given the DAA Issuer has as its customer base entities that are mutually suspicious. There would be a potential for collusion.
-Ned

On 6/7/21, 12:58 PM, "RATS on behalf of Christopher Newton" <[email-masked] on behalf of c.newton=[email-masked]> wrote:

    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.

    --
    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: 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,

    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://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

    On 06/06/2021, 21:12, "Christopher Newton" <[email-masked]> wrote:
    > > 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.

    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 28 Jun 2021 18:12:03 +0000

Also, if Endorsements includes public keys (which could include group public keys) then The flow from the DAA Issuer (group public key) is itself a form of Endorsement. The DAA Issuer is a type of Endorser. Hence, the RATS Arch diagram is still relevant (and possibly doesn't need to be modified by this draft). 

Rather, it might make sense to describe the DAA Issuer as an Endorser that that creates DAA public keys as Endorsements. As an Endorser, the DAA Issuer might be a device manufacturer. The cred req / cred rep messages might be part of a manufacturing process that doesn't require standardization but might benefit from it nevertheless. Alternatively, the DAA Issuer might be a service that Endorsers subscribe to, itself an Endorser. Maybe the draft should describe some of the viable deployment options and not stereotype a particular option? 
-Ned

On 6/28/21, 9:14 AM, "RATS on behalf of Smith, Ned" <[email-masked] on behalf of [email-masked]> wrote:

        Hi Thomas,

        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,

        cheers, t

---

From: Christopher Newton <[email-masked]>
Date: Mon, 28 Jun 2021 20:26:24 +0000

Dear Ned,

Thank you for your thoughtful comments.

We agree that the DAA Issuer is the same as the TCG's Privacy CA. For the TPM the endorsement key is an encryption key and we need a CA to create a credential for a DAA key.  The DAA Issuer can be considered as an Endorser in the RATS scheme, in that the issue of the credential for a DAA key and the publication of their public key enables a Verifier to validate an Attesters (DAA) signature on the attestation. However, there has to be an interaction between the Attester and the DAA Issuer to provide a credential for the DAA key and this should be allowed for in the RATS scheme.

The manufacturer could act as the DAA Issuer, but if this was done as part of the manufacturing process the attester cannot later on ask for more DAA keys.

Even if the DAA Issuer and Endorser collude, the privacy of the Attester is guaranteed by the DAA scheme. The credential and the DAA public key are not given to the verifier. Verification uses the DAA signature and a randomised credential.

We hope that this is clear, if you have any questions please let us know.

Regards,

Chris and Liqun.

________________________________
From: Smith, Ned <[email-masked]>
Sent: 28 June 2021 19:12
To: Newton, Christopher Dr (Computer Science) <[email-masked]>; Thomas Fossati <[email-masked]>; [email-masked] <[email-masked]>
Cc: Chen, Liqun Prof (Computer Science) <[email-masked]>; [email-masked] <[email-masked]>; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] Review of draft-birkholz-rats-daa

        Hi Thomas,

        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,

        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%7Cd6da4d45bbe14a72a5af08d93a6044db%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637605007410642870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=Ve%2F6PwHX1vSRGQuDDFAYAyikOYaO%2FIPTigKgWwvvyCI%3D&amp;reserved=0

        _______________________________________________
        RATS mailing list
        [email-masked]
        https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=04%7C01%7Cc.newton%40surrey.ac.uk%7Cd6da4d45bbe14a72a5af08d93a6044db%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637605007410642870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=fovtlFz6huIJ%2Bsha%2BFbcTWi3D%2FXJv%2BIj6uUyOOa0nI0%3D&amp;reserved=0

    _______________________________________________
    RATS mailing list
    [email-masked]
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=04%7C01%7Cc.newton%40surrey.ac.uk%7Cd6da4d45bbe14a72a5af08d93a6044db%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637605007410642870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=fovtlFz6huIJ%2Bsha%2BFbcTWi3D%2FXJv%2BIj6uUyOOa0nI0%3D&amp;reserved=0

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 29 Jun 2021 00:57:28 +0000

See inline.

From: Christopher Newton <[email-masked]>
Date: Monday, June 28, 2021 at 1:27 PM
To: "Smith, Ned" <[email-masked]>, Thomas Fossati <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Liqun Chen <[email-masked]>, "[email-masked]" <[email-masked]>, Henk Berkholz <[email-masked]>
Subject: Re: [Rats] Review of draft-birkholz-rats-daa

Dear Ned,

NMS> What prevents this?

Even if the DAA Issuer and Endorser collude, the privacy of the Attester is guaranteed by the DAA scheme. The credential and the DAA public key are not given to the verifier. Verification uses the DAA signature and a randomised credential.
NMS> If the DAA Issuer is colluding, potentially everything the DAA Issuer is in possession of, the Verifier also is in possession of. This includes knowledge about the size of the group. I think it is very important to state all of your assumptions. One important assumption should be that the verifier is capable of performing differential privacy analysis (DPA) on all information produced by Endorsers and the Attester. If DAA Issuer is “trusted” then it would be necessary to identify which information is (MUST?) not be available to the ecosystem to sufficiently resist DPA.

Regards,

Chris and Liqun.

        Hi Thomas,

        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,

        cheers, t