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

[Christopher Newton <[e-mail]>]

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 <[e-mail]>
Sent: 28 June 2021 19:12
To: Newton, Christopher Dr (Computer Science) <[e-mail]>; Thomas Fossati <[e-mail]>; [e-mail] <[e-mail]>
Cc: Chen, Liqun Prof (Computer Science) <[e-mail]>; [e-mail] <[e-mail]>; Henk Birkholz <[e-mail]>
Subject: Re: [Rats] Review of draft-birkholz-rats-daa

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" <[e-mail] on behalf of [e-mail]> wrote:

    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" <[e-mail] on behalf of c.newton=[e-mail]> 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 <[e-mail]>
        Sent: 07 June 2021 11:08
        To: Newton, Christopher Dr (Computer Science) <[e-mail]>; [e-mail]
        Cc: Henk Birkholz <[e-mail]>; [e-mail]; Chen, Liqun Prof (Computer Science) <[e-mail]>; Thomas Fossati <[e-mail]>
        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%7Cd6da4d45bbe14a72a5af08d93a6044db%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C1%7C637605007410642870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=Ve%2F6PwHX1vSRGQuDDFAYAyikOYaO%2FIPTigKgWwvvyCI%3D&amp;reserved=0

        On 06/06/2021, 21:12, "Christopher Newton" <[e-mail]> 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 <[e-mail]>
        > Sent: 26 May 2021 13:04
        > To: [e-mail]
        > Cc: [e-mail]; Thomas Fossati <[e-mail]>
        > 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
        [e-mail]
        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
    [e-mail]
    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