In case of using Privacy-CA model, the authenticator has Endorsement key (EK) which is long-term key like attestation key in Basic Attestation model.
In stead of using EK directly for the attestation during registration, the authenticators uses Attestation Identity Keys (AIKs) which are very short-term keys.
These keys are generated during AIK certificate enrollment process between the authenticator and the Privacy-CA, which is trusted component and honors privacy of the authenticator. If the privacy are concerns, these keys can be generated as many as possible if there are room for maintaining the keys.
During enrollment process, Privacy-CA cannot get any information regarding RP to which the authenticator will attest.
So, if the authenticator uses different AIKs per RP during registration, the privacy of authenticators can be satisfied among different RPs.
As a result, we don't have to change toBeSigned structure for Privacy-CA type of attestation.

There might not be an enrollment process between the authenticator and the Privacy-CA. There is not, for example, in current U2F tokens.

As an alternative to Dirk's scheme, the RP ID should be replaced in the signed message with H(blind + RP ID). The Privacy-CA would still see the structure of the message that it was signing, but the blind would only be disclosed to the RP by the client.

In WebAuthn spec, there are supported attestation types including Privacy-CA.
Is this a proposal to add more attestation type? I think Dir's scheme is not regarding Privacy-CA defined in WebAuthn and TPM specs. In stead, it seems like proxy signature or blind signature scheme.

@nadalin Can we front-load this issue in this week's call as this is a breaking change?
@balfanz/@leshi Can you guys create a PR for your proposal??

@christiaanbrand we agreed that we will keep this open, but you will create a new issue that describes making a new packed attestation format so this becomes a non breaking change

To Adams comment, I am more comfortable with just blinding the "CA" to the RP ID rather than removing the audience totally.
It may be a mistake to call this a privacy CA. It is more of a blinding proxy for the attestation.

If the RP ID can be hashed with a nonce before going to the fido client then CTAP would not necessarily need a new attestation format. The proxy would need a new attestation type so that the client would know how to verify the blinded RP_ID but other than that the packed format could stay the same.

In this blinding scheme, what gets passed to authenticator at authenticatorGetAssertion time? If it is not the same as of authenticatorMakeCredential time, how will authenticator finds out the credential?? If it is same, who remembers that nonce on different platforms?

Good point. That method of blinding won't work.

That leaves us with needing to change the attestation from the Authenticator to support this.

What are the security implications of leaving a audiance out of the attestation. Is there anything else that is currently passed to the Authenticator that could also be used as an audiance?

The format returned needs to work both directly and with a privacy CA or whatever it is called or it will require opening up CTAP just when we thought that we were done.

I agree and we want all the current security assurances from the new scheme also (like able to tie together RPID with the credential in the signature.)

We need to see @leshi / @balfanz / @christiaanbrand proposal quickly on this.

If I understand it correctly, @balfanz is saying something like this

Current Attestation Format:
alg: COSE Algorithm Identifier
Sig: SIGNATURE(Attestation Key, alg, authenticatorData || ClientDataHash)
X5C: Attestation Key Cert Chain

Proposed Attestation Format:
alg1: COSE Algorithm Identifier
Sig1: SIGNATURE (Created Credential Key, alg1, authenticatorData || ClientDataHash)
alg2: COSE Algorithm Identifier
Sig2: SIGNATURE (Attestation Key, alg2, Created Credential Public Key in COSE KEY Format)
X5C: Attestation Key Cert Chain

In case of privacy CA, "Attestation Key" is replaced with "Privacy CA Key"

Dirk's proposal seems like delegation of generating attestation signature from the authenticator to the Privacy CA (actually it's not in the context of TPM and WebAuthn). This is sometimes called proxy signature scheme. Usually, this approach is used in the applications like grid computing and mobile computing which the client has a limited resources to sign the message. It's not for the privacy of the original signer (authenticator and user).
In current WebAuthn spec there is no such delegation of signing right to other components, which has some privacy risk of leaking to-be-signed message to the proxy signer.
I think we need to clarify what we want to solve.

Closing with no action per decision at 11-Oct-17 working group meeting.