Packed and U2F Attestation Statements' verifications don't differentiate between Basic and Privacy CA Attestation Types

[jcjones]

The Packed Attestation Statement Format is valid for all Attestation Types.

webauthn/index.bs

Lines 2313 to 2317 in b8c6027

	: Attestation statement format identifier
	:: packed
	: Attestation types supported
	:: All

However, in its verification procedure it assumes that if x5c is present, that attestations are type Basic:

webauthn/index.bs

Lines 2387 to 2393 in b8c6027

	3. If |x5c| is present, this indicates that the attestation type is not [=ECDAA=]. In this case:
	- Verify that |sig| is a valid signature over the concatenation of |authenticatorData| and |clientDataHash| using the
	attestation public key in |x5c| with the algorithm specified in |alg|.
	- Verify that |x5c| meets the requirements in [[#packed-attestation-cert-requirements]].
	- If |x5c| contains an extension with OID `1 3 6 1 4 1 45724 1 1 4` (id-fido-gen-ce-aaguid) verify that the value of this
	extension matches the <code>[=aaguid=]</code> in |authenticatorData|.
	- If successful, return attestation type Basic and trust path |x5c|.

However, that's what the Privacy CA attestation will look like, too.

Similarly, it's technically feasible for a browser to use the Privacy CA option for U2F, and we might want to do so for - say - private browsing mode. Yet U2F Attestation Format suffers the same issue -- in addition, it excludes Privacy CA which seems wrong, as it'd be useful:

webauthn/index.bs

Lines 2686 to 2690 in b8c6027

	: Attestation statement format identifier
	:: fido-u2f
	: Attestation types supported
	:: Basic, [=self attestation=]

[emlun]

I'm not sure having Privacy CA as a separate attestation type is very meaningful, as like you say (and @balfanz notes in #628 (comment)), to the RP it looks and act the same as Basic Attestation. I would suggest merging the two concepts, but I'm not sure how that would affect the TPM attestation statement format which seems to be intimately connected to the Privacy CA model.

[Kieun]

In the view point of RP, RP cannot differentiate between Basic and Privacy CA from the attestation data. Since both attestation data have same structure having x5c. So, if x5c is present, it would be Basic or Privacy CA attestation type. Thus, the verification procedures for both are same.
The thing is that there is no way for RP to know that received attestation is Basic or Privacy type. Sometime, RP may want to get attestation types for evaluate security and privacy risk.

[equalsJeffH]

@jcjones notes in webauthn f2f tpac 2017-11-09 that we can push this to PR, we can address it with non-nomative editorial language. the present text is misleading.

[jcjones]

The verification procedures still need to be updated, but I fixed the omission of Privacy CA for U2F in 5f4f3e6

[equalsJeffH]

fyi: "privacy CA" is now "attestation CA", I believe.

[selfissued]

Per the 28-Feb-18 call, @jcjones will verify that this has been addressed.

[jcjones]

I confirm this has been addressed. Closing this issue.