-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AID format in APT TLV 0x4F #43
Comments
In response to: "Addendum: sub-tag 0x4F in TLV 0x79 is apparently expected to contain only the RID" As OpenSC developer for PIV, the real source should be NIST sp800-73-4 and accept sp800-73-3 as there are many of these in the field. 800-73-3 superseded 800-73-2 in 2010, appears to be the same as 800-73-4 in regards to AID. I had though it should contain the full 11 bytes. But all the demo cards return for 4F 79 the 5 byte RID. See the examples from 2 early NIT demo cards and one 2020 Idemia ID-One based sp800-73-4below. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf "Part 2 - Table 4 Coexistent Tag Allocation Authority Template (Tag '79') " says: But I did find in sp800-73-1 from 2006, and superseded in 2008: Table 9. Data Objects in a Coexistent Tag Allocation Authority Template (Tag '79') This implies that the RID might not be the same as what is in the AID, although it appears they are the same 5 bytes now. and in the 79 4F it should be the 5 byte RID. ISO-7816 is one of the most complicated standards I have ever seen. I suspect this is why NIST wrote sp800-74 to spell out what subset of ISO 7816 it would require in a PIV applet or application. For reference purposes I include the following: ISO 7816-4 Table 122 — "Interindustry DOs for application identification and selection" " 8.3.6 Coexistent tag allocation scheme" says: These tag allocation schemes may use tags with an interpretation not defined in ISO/IEC 7816 [6]. In order to identify a coexistent tag allocation scheme and the authority responsible for the scheme, an interindustry DO'79' shall be used. This DO shall nest one of the interindustry DOs shown in Table 16. "If an authority is valid within a file or application, then DO'79' shall be present in the EF, DF or application Example of demo cards: Early NIST demo card 1 using T=0 from Gemalto PIV 1.5.5 appears to violate the standard for 4F and for 79 4F. Early NIST Demo card 2 using T=1 Oberthur ID-One PIV (Type A): Idemia ID-One PIV 2.4.1 demo card based on 800-73-4 support for SM: |
Honestly, I think at this point Postel's law should indicate to client implementations to support both. There's clearly a mix of interpretations out in the wild. I feel like the GnuPG developers are doing themselves and their users a disservice by being too strict on this particular fine point. For this applet, I'm happy to change to the 0x79 0x4F containing just the 5 bytes, since I think that makes sense. For the top level 4F in the APT, maybe we should provide a build configuration option? |
I agree re Postel's law. I have sent a suggestion and patch to gnupg-devel to be more flexible, but it seems to be stuck in moderation. After playing with their PIV feature a bit more it seems that it's still pretty far from being ready to release anyway. Based on Doug's reply 5-byte 79 4F sounds nice. I guess an option for the top-level 4F format would work, since the current way seems more in the spirit of SP-800-73-x but someone may want maximum Yubikey compatibility. |
* scd/app-piv.c (app_select_piv): Allow for full AID. -- It appears that SP-800-73-x is not too clear about the format of these objects. Many current cards (such as the Yubikey 5 series) apparently have only the PIX in DO 0x4F and only the RID in object 0x79/0x4F. However, other cards as well as the PivApplet Javacard applet have the full AID in 0x4F (which actually seems closer to what the standard says). PivApplet also has the full AID in 0x79/0x4F, but this is probably incorrect. (Here is a long discussion of the matter from an OpenSC author: arekinath/PivApplet#43 (comment)) [Taken from a mail to gnupg-devel date 2021-02-03.] Signed-off-by: Werner Koch <wk@gnupg.org>
GnuPG 2.3 will include direct PIV support and I was going to give it a try with a PivApplet card. Unfortunately I didn't get far: PivApplet returns an APT where object 0x4F has length 11 and it contains the full AID, while GnuPG expects the object to have 6 bytes and contain only the PIX + version without the RID.
OpenSC sources @ https://github.com/OpenSC/OpenSC/blob/0d693f63cbebda1440f1468eb30c35b7a278f7e9/src/libopensc/card-piv.c#L718 indicate that "early Yubikeys" also returned the full AID, but apparently new ones don't (a Yubikey 5 I have returns PIX+version only). SP 800-73-4 isn't really clear on the matter. Part 2 section 3.1.1 comment regarding tag 0x4F just states that "The PIX of the AID includes the encoding of the version of the PIV Card Application."
What's your take on what the object should contain? I think GnuPG ought to support both versions since both kinds of cards are in the wild, but no idea whether the developers will budge.
Addendum: sub-tag 0x4F in TLV 0x79 is apparently expected to contain only the RID (which is what's there on a Yubikey) and not RID+PIX.
The text was updated successfully, but these errors were encountered: