Personalisation tool should allow proprietary URIs in NDEF payloads

[alexjfisher]

Hi

I want to program our yubikey neos with the following URI 'anyconnect://connect/?host=vpn.example.com&prefill_secondary_password=' This should allow me to use the yubikey neo with the cisco anyconnect client in a user friendly way.

But the tool won't allow URIs beginning with anything other than http, https, ftp etc. I've looked at the document nfcforum-ts-rtd-uri-1.0.pdf mentioned in ykpers.c and proprietary URIs should be fine (See example A.3 'Storing a Proprietary URI on the Tag')

Kind Regards, Alex

[klali]

Hello,

I've just added missing error checks to ykpersonalize. What happens is that the url may only be 53 bytes long (subtracting the prefix if it's in the list of known prefixes).

/klas

(edited, typo in the original, the limit is 53 bytes)

[alexjfisher]

Ahh... That (unfortunately) makes sense. Why else would there be a scheme to save bytes? :(

During my testing, switching out anyconnect:// for https:// would have saved me 13 bytes. Maybe I can petition cisco, (or maybe an anyconnect developer will stumble across this post!), to provide some short parameter aliases. prefill_secondary_password is 26 bytes :(

[alexjfisher]

What's really irritating is I think I'm only 1 byte over if I use the shortest uri possible... anyconnect:connect?name=A&prefill_secondary_password=

Which together with the 5 bytes header is 58.

Is the 57 byte limit specific to the yubikey neo or part of the standard? Thanks, Alex

[klali]

I made a typo in my previous comment, the limit is 53 bytes: https://github.com/Yubico/yubikey-personalization/blob/master/ykcore/ykdef.h#L181 the first byte of the data field is used for shortening the url, or 0 if it's not shortened.

It's a neo limitation, existing so it can be programmed over the standard interface, where the ndef_st in ykdef.h must fit inside the payload of the frame_st.

/klas

[alexjfisher]

I'm almost certainly missing something, but... I make ndef_st only 62 bytes (1+1+54+6=62). frame_st.payload is 64 bytes?

[klali]

No, you're not. The reason for that discrepancy is probably that someone made an error in calculating that when creating the struct originally.. =(

[alexjfisher]

Why the sad face? Doesn't this mean I can change NDEF_DATA_SIZE to 56?

[klali]

No.. Firstly because the limit is in the hardware as well that the data is 54 bytes, and because of the struct alignment, with a 6 byte accesscode following directly after the data. So increasing it to 56 bytes at this point would be a major headache, requiring different structures for different hardware revisions.

[alexjfisher]

Shame. Whilst just a single extra byte would have helped me a lot, it hardly seems worth creating new firmware and supporting both versions for just 2 extra bytes. 10's of extra bytes would allow all the anyconnect uri options to be useable.

I guess I'll just have to host a webpage somewhere that redirects https requests to anyconnect uris. Not a great solution, but I guess it should work ok.

Thanks for your help, Alex