Treating credential as self attested

118 views
Skip to first unread message

Andrey Paramonov

unread,
Apr 10, 2023, 5:25:41 PM4/10/23
to FIDO Dev (fido-dev)
The note to the last step in 7.1. Registering a New Credential says

"However, if permitted by policy, the Relying Party MAY register the credential ID and credential public key but treat the credential as one with self attestation"

Would such a policy be legitimate only for packed attestation (which in principle supports self attestation)? or for any attestation with a cert chain?

For example: Suppose TPM attestation was used, but x5c doesn't chain up to an acceptable root cert (hypothetically). Should the registration be permitted, if I have such a policy in place, or failed regardless of the policy because TPM attestation cannot support self attestation in general?

My1

unread,
Apr 10, 2023, 5:44:22 PM4/10/23
to Andrey Paramonov, FIDO Dev (fido-dev)
honestly if you have no problem with self-attestation, cert based attestation from unknown certs as long as it is functionally valid (and you dont have another reason to actively deny it) should in my opinion totally be fine, as while you cannot confirm the source of the attestation you cannot really do that on self either.

you usually either have a list of acceptable roots while denying self attest, or you allow self attest and mostly dont care about the certs, as allowing self attest would defeat the purpose of having a whitelist of root certs.

Regards
My1

This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/6bb331e6-cb1a-4604-9f05-115d3d3f0b04n%40fidoalliance.org.

Andrey Paramonov

unread,
Apr 11, 2023, 1:37:58 PM4/11/23
to FIDO Dev (fido-dev), My1, FIDO Dev (fido-dev), Andrey Paramonov
To continue your line of thought, there is another policy in step 23:

"If self attestation was used, verify that self attestation is acceptable under Relying Party policy."

And I'd like to know how/if that policy should be related to the one that allows untrusted cert chains.

One way to resolve the confusion is to conflate the two policies into one: "If you allow self attestation, you should allow untrusted cert chains as well". In this case the note to step 27 should just reference the policy from the step 23.

Or we can keep the two policies separate, but then we need to clarify 1) which attestation format(s) the "allow untrusted cert chains" policy is applicable to, and 2) how it should work together with "allow self attestation" policy.

My1

unread,
Apr 13, 2023, 1:36:02 AM4/13/23
to Andrey Paramonov, FIDO Dev (fido-dev)
Well reading this policy part for what might be the first time lol, 22 and 23 can basically condensed to:
1) "technically establish your trust policy"
2) verify the attestation used is within that trust policy
and I'd personally throw a green note box for some common sense policy points in there that if:

1) if no attestation is allowed, self attestation should equally allowed, if the RP is incapable of actually handling the attestation just check if it looks like one ("packed" and no "x5c") and treat just the same as none, maybe.
2) if self-attestation is allowed or by extension of 1, no attestation, you should not enforce attestation certificates chaining to a "trusted root" (as a non-"trusted" authenticator can just be stripped of its attestation)
3) equally if trust certificates are not enforced, it would make sense to also allow no and self attestation, as people could just add their own custom attestation to the response if they really want.

One thing I am currently not sure of is what self attestation really is for, I mean what does it really change from sending over no attestation?

Regards
My1

John Bradley

unread,
Apr 13, 2023, 11:33:36 AM4/13/23
to My1, Andrey Paramonov, FIDO Dev (fido-dev)
Self is used by authenticators like Chrome that can’t or don’t securely manage their batch keys.  
It allows an authenticator to provide an AAGUID but with the understanding that any authenticator could impersonate the AAGUID.

So think of it as a AAGUID hint.  This might help with UX, but should not be used for security, in that any authenticator could claim to be that AAGUID.

John B.

My1

unread,
Apr 13, 2023, 11:39:53 AM4/13/23
to John Bradley, Andrey Paramonov, FIDO Dev (fido-dev)
I see so because with none you don't even throw an aaguid, you can at least claim to be one as a neat hint? Interesting.


The mooltipass i use also uses self, websites seem to have problems tho so i usually chop off the attestation with chrome
Reply all
Reply to author
Forward
0 new messages