CTAP Preview versions in production devices

[My1]

How can devices that use specifications that are marked as Preview ESPECIALLY if these specifications arent even public for others to implement be certified? my problems with this are as follows:

a) it gives the big people (especially Yubico) an unfair market advantage, and the reasoning to not have keys sold with a clearly preview standard obviously cannot apply seeing yubico selling these before any standard on the vendor commands got public. In fact the first public CTAP 2.1 standard I can find only mentions the vendor commands but the links go 404. In fact even the newest public iteration from just about a month ago mentions the preview commands in the vendor space more in an offhand manner and provides no documentation on HOW to actually implement these, which is obviously bad as devices using the Prototype Commands have been sold widely enough (mainly by Yubico), and it would be bad if clients cannot implement anything for these keys for the lack of documentation, giving the bigger companies in the FIDO Alliance that can get the secret specs and also make clients yet again a huge advantage, creating a kind of vendor lock in effect. 

b) almost all FIDO2 keys cannot be updated to accompany newer specs so if there are bugs or spec changes and all devices the users has are these, the user is in a pretty bad state.

c) I have seen only ONE SINGLE INSTANCE where users are actually seeing ANYTHING that the keys are running on a FIDO2 standard marked as preview, meaning users expect a fully working key and in fact are basically abused as beta testers.

[John Bradley]

I have been pushing to make all Fido drafts bublic for a long time, so i apprecite and largley agree with your frustration.

However that is not yet the world we live in.

After CTAP2.0 was published a couple of things happend. 

1) outside of the fido spec Microsoft published two vendor extensions that they required be supported for authenticators that they promoted as workig with windows.

    a) credential managent command 0x41 ( windows has a API for it but no UI, Chrome impliments it on non windows platforms)  https://fidoalliance.org/specs/fido2/vendor/BioEnrollmentPrototype.pdf

    b) bio enrollment command 0x40  (This has been implimented by Windows and Chrome and used by the Feitian  Biopass and a limited number of bio authenticator vendors) https://fidoalliance.org/specs/fido2/vendor/CredentialManagementPrototype.pdf

The links are in CTAP2.1 RD 20191217 https://fidoalliance.org/specs/fido2/fido-client-to-authenticator-protocol-v2.1-rd-20191217.html

I can't tell at this point if the specifications downloads page pointed to the correct version on the specs/fido2 directory or the one that you found.

Currently it points to the new CTAP2.1 RD 20201208 and the documentations are linked from two places in the text.

At the same time in order to agree to support resident credentials in chrome Google proposed the credProtect extension, and said they would support rk but make credentials at credprotect level 2 by default so that they could only be trtreved with some form of user verification in order to protect user privacy.

That extension was the main change in CTAP2.1 RD 20191217 from CTAP2.0, but as an extension it can work with any version of CTAP including CTAP2.0  There is nothing CTAP2.1 specific about it bust that the WG chose to publish it in that spec rather than creating a separate document.

It is true that for the two vendor commands Microsoft put into feature detection that the version needed to be FIDO_2_1_PRE.  That wasn't strictly needed as "credentialMgmtPreview" and "userVerificationMgmtPreview" are both in getInfo optikons if those commands are supported.

In retrospect putting FIDO_2_1_PRE in the versions sting was probably a mistake, it is atleast a pin in the ass.

So the 3 features really do not require CTAP2.1.  In fact the final bio-enrollmant and credential namagement commands for the official Fido caommands did change and are on separate command numbners.

Chrome supports both the new and the old commands abd will prefer the new ones on CTAP2.1 autenticators.  Windows will support the the new commands in a upcoming releas that is in testing. 

The credprotect extension was not changed and is republished in the final spec.

As far as I know all the authentictors are currently certified as CTAP2.0 and some have impimented extensions and or vendor features that are not part of certification.

I am personally working with members of the certifiaction working group on CTAP2.1 certification and interoperability tests, those will include backwards compatibility tests for CTAP2.0 and CTAP1/U2F for authenticatos that impliment those features.   The credprotect extension is tested, but I don't think there are tests for the vendor 0x40 and 0x41 commands, Microsoft however has tests for those as part of their program.

It is a bit sad that in the specification process, not counting platform authenticators there are really only two authenticator companies that activly participate.

Makeing the specification sausage is not a pretty buisness, but I would not ascribe evil intent to the participants, mostly over work and normal human failings.

Your participation would be welcomed as you seem to have an intrest.

Regards

John B.

--
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/9cc69274-29de-4bc0-beac-73a987fe907fn%40fidoalliance.org.

[My1]

okay so the 20191217 rd exists twice at different locations, now this is fun.

my main issue 

also regardless of "FIDO_2_1_PRE" or not being needed the fun part is that there are now 2 ways of accessing cred management and bio enroll. either via the vendor commands or via the now official commands, and you cannot just deprecate the vendor commands out of existance since makers of security keys (mainly yubico) have made them into production devices that cannot be updated.

I am not saying that there are evil intents behind the specs being private, but it definitely doesnt have good effects. I once read that the point of that was that these preview specs shouldnt be used to make productive stuff, but well let's look at Yubico.

to be totally honest I would loke to propose that fido devices that use features that rely on preview stuff must be able to be updated either out of it or at least to the next stable version (although my ideal would be just generally updates till they die, like with solo) and frankly I am not even sure how certification and attestation should go with these devices as they run on a spec that might be flawed or not supported in the future. and considering people are supposed to use these devices to secure their identities for years to come, this stuff should not be that crazy.

also may I add that not having cred mamanegent in 2.0 was in my opinion a massive oversight? I mean it would be like having a harddrive where you cannot delete the contents except by formatting but you cannot copy off the contents before doing so (and also the fact that non-RKs are being grilled as well doesnt make this any better)

[John Bradley]

I have asked Fido staff to try and fix the links.  Thanks for pointing that out.   The same document is in two diffrent directories and probably also dosen't need to be duplicated.

I will grant you that perhaps credential management should have been in CTAP2.0 but hindsite is 20/20.   Again your participation is welcome going forward.

So yes there are two ways to acess simmilar functionality.   The new credential management has a number of usefull new features to allow editing of display names etc so did change from the original Microsoft proposal.

The vendor preview commnds that are not part of certification and optional for authenticators to impliment.  Those commands have not changed. 

I expect that as it is going to be some time before all current windows versions are updated authenticators will probably hve an incentive to continue supporting thos commands for several years.

Also Windows after it updates to CTAP2.1 is going to keep supporting existing keys for some time, you need to ask them how long.

Again these are vendor commnds published by Microsoft in the vendor reserved range of 0x40 and above.   The public CTAP2.1 20191217 spec did have links to them to help implimentors find them.   Perhaps not sufficient information for everyone granted.

Anyone can publish and impliment commands for that range, the CTAP2.0 spec is extensable.   Microsoft only really supports the Bio Enrollment commnd, that is not used any Yubico production key, but used by some Biokeys like Onespan, Feitien and perhaps others.  I don't have a list.

I am not quite sure what you are proposing?   That vendor extensions not be allowed?

If it is that all the specs be publicly availbale then I am 100% behind that idea.   I think public review only of RD draft snapshots is counter productive.   However I beleve that when that was last presented to the Fido board it was pushed off for consideration untill after CTAP2.1 is completed.   Perhaps the board can reconsider that in 2021.

It is true that Fido members cant publicly sell authenticators as Fido2.1 authenticators untill after the board ratifies the spec.   However vendors have been selling CTAP2.0 authenticatos with some vendor extensions during 2020 as the extensions were supported by Windows and Chrome and had utility to users.  None of those keys will loose functionality when platforms ship CTAP2.1 support.

Currently Safari dosen't support any vendor extensions and I don't know if they have any plans to support credential management or bio-enrollment at all.  You will need to ask Apple about that.

Updatable keys would be nice if it can be done securly.   Some vendors support updating and others not.  There are good reasons for not supporting it, but that is whole other debate.

The working group needs to look at how changes between spec releases are handeled.  Perhaps if the WG can get onto a more frequent spec publishing cycle it will be less of an issue.

I don't think where we are is a disaster, but we can always do better in the future.

Regerds

John B.

[My1]

> Also Windows after it updates to CTAP2.1 is going to keep supporting existing keys for some time, you need to ask them how long.

precisely that part gets me worried. with windows 10 Microsoft is getting increasingly fast making windows a more moving target than ever, as single builds are iirc only supported for like 18 months and LTS is only available to enterprise users.

> I am not quite sure what you are proposing?   That vendor extensions not be allowed?

obviously not, vendor extensions, if used correctly, are awesome.

my problem is the combination of the following factors:

• preview spec
• commands, options, extensions etc. in it that are still subject to change (vendor or otherwise)
• sold on production devices with no hint for this at all
• no ability to update to a "stable" state
• (optional but makes it definitely worse than it already is) no sufficient public docs on the stuff or those docs being badly accessible

> It is true that Fido members cant publicly sell authenticators as Fido2.1 authenticators untill after the board ratifies the spec.

well maybe they are not saying they are FIDO2.1 but my problem is more that they are not saying they use a spec that is still in review phases regardless of the version number.

> Updatable keys would be nice if it can be done securly.   Some vendors support updating and others not.  There are good reasons for not supporting it, but that is whole other debate.

sure while I am personally against devices that cannot be updated for many reasons including environmental, this is enhanced when devices use preview specs.

I dont wanna call names, but I have some Fido devices which have 2.1 in the earlier preview with the vendor commands but they didnt properly work when abused a bit too much (notably credential management was completely busted when loading too many RKs in, or kinda glitched when multiple relying parties are involved).

Problem though is that clients just expect these devices to work as they advertise the features in getinfo, users are in no way informed that the functions the devices used were essentially in beta and could stop working at any time for any reason.

when vendors really want to make FIDO devices with no ability to be updated, then do not use preview specs, simple as that.

> I don't think where we are is a disaster, but we can always do better in the future.

sure and that's why I am writing these, I don't want it to become an actual disaster in the future.

Regards