Skip to content
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

Closed
vuori opened this issue Feb 2, 2021 · 3 comments
Closed

AID format in APT TLV 0x4F #43

vuori opened this issue Feb 2, 2021 · 3 comments

Comments

@vuori
Copy link

vuori commented Feb 2, 2021

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.

@dengert
Copy link

dengert commented Feb 3, 2021

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 1 - 2.2 PIV Card Application AID"
"Part 1 - 3.3.2 Discovery Object"
"Part 2 - 2.3 Card Applications"
"Part 2 - 3.1.1 SELECT Card Command"
"Part 2 - Table 3 Data Objects in the PIV Card Application Property Template (Tag '61')" which says:
"Application identifier of application '4F' - M - The PIX of the AID includes the encoding of
the version of the PIV Card Application. See Section 2.2, Part 1." (I read this as the full 11 bytes.)
"Coexistent tag allocation authority '79' - M - Coexistent tag allocation authority template.
See Table 4."

"Part 2 - Table 4 Coexistent Tag Allocation Authority Template (Tag '79') " says:
" Application identifier '4F' - M - See Section 2.2, Part 1" (I also have read this as the full 11 bytes but all the demo cards below only return 5 bytes, i.e. NIST, the authority for PIV. This make sense because a Coexistent Tag Allocation Authority would be the authority i.e. NIST i.e. the NIST RID. And not include an application. But I can not find it stated in a document, only in the example cards. )

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')
Description Tag M/O Comment
Application identifier ‘4F’ M NIST will post the PIV RID on
http:///csrc.nist.gov/piv-project and will publish it in a
technical note.

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"
"'61' Set of application-related DOs"
" '79' under DO'61' this DO indicates a coexistent tag allocation scheme" (This is the PIV case.)

" 8.3.6 Coexistent tag allocation scheme" says:
"In such a scheme, all the interindustry DOs shall be nested within interindustry DOs'7E'. Moreover, tags '79' and '7E' shall not be given another interpretation (The PIV Discovery returns '7E' so needs to follow the same restrictions.

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
DF management data (see 7.4), or in the current template set by any file selection."

Example of demo cards:
(Note; last 00 in the -s string is Le=00)
When I got these cards early from NIST I recall a comment about a shortage of cards and so 2 cards are from Gemalto and the rest from Oberthur.

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.
./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00"
Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00
Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00
Received (SW1=0x90, SW2=0x00):
61 11 4F 06 00 00 10 00 01 00 79 07 4F 05 A0 00 a.O.......y.O...
00 03 08

Early NIST Demo card 2 using T=1 Oberthur ID-One PIV (Type A):
./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00"
Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00
Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00
Received (SW1=0x90, SW2=0x00):
61 39 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79 a9O............y
07 4F 05 A0 00 00 03 08 50 0E 49 44 2D 4F 6E 65 .O......P.ID-One
20 50 49 56 20 42 49 4F 5F 50 10 77 77 77 2E 6F PIV BIO_P.www.o
62 65 72 74 68 75 72 2E 63 6F 6D 7F 66 08 02 02 berthur.com.f...
80 00 02 02 80 00 ......

Idemia ID-One PIV 2.4.1 demo card based on 800-73-4 support for SM:
./opensc-tool -s "00:A4:04:00:09:A0:00:00:03:08:00:00:10:00:00"
Using reader with a card: SCM Microsystems Inc. SCR 355 [CCID Interface] 00 00
Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00
Received (SW1=0x90, SW2=0x00):
61 2C 4F 0B A0 00 00 03 08 00 00 10 00 01 00 50 a,O............P
0A 49 44 2D 4F 6E 65 20 50 49 56 61 09 79 07 4F .ID-One PIVa.y.O
05 A0 00 00 03 08 AC 06 80 01 2E 06 01 00 7F 66 ...............f
08 02 02 03 F8 02 02 7F FF .........

@arekinath
Copy link
Owner

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?

@vuori
Copy link
Author

vuori commented Feb 4, 2021

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.

arekinath added a commit that referenced this issue Mar 1, 2021
gnupg-com pushed a commit to gpg/gnupg that referenced this issue Mar 12, 2021
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants