Uruguayan eID: document how to decode the identity data objects

[nicolasgutierrezdev]

Follow-up to #33, where @frankmorgner asked for an example of how to get the
face image and the ID data in human readable form instead of the raw encoding.

Adds a "Decoding the identity data objects" section covering the four PKCS#15
data objects (7001, 7002, 7004, 700B): tag, length form and value type
for each, the 1F xx field tags of the biographic data, how to get the portrait
out as a plain JPEG, and how to split the MRZ into TD1 or TD3 lines.

Two things worth flagging for anyone consuming this data: the biographic text fields
are UTF-8, not ASCII, and the surname split between 1F 01 and 1F 02 is not
reliable, some cards pack both surnames into 1F 01.

Layouts come from AGESIC's public technical documentation and from reading real
cards.

[carlosplanchon]

Cross-checked this against AGESIC's technical documentation and against a v4
card, and opened nicolasgutierrezdev#1 against this branch with the
result. Merging that one updates this PR.

The TLV skeleton holds up exactly as written here: 5F 01 with a fixed length of
9, 1F 01 to 1F 06, 3F 01 with a long-form length, 7F 01, and the three
length forms with the same offsets. The document even carries the same worked
example for the portrait, T=0x3F01 L=0x8223FE.

The main find is that 1F 08 is the date of issue, four bytes of packed BCD
in DD MM YY YY order. The documentation mentions a date of issue exactly once,
to say it is the one value that is not ASCII, and never says which tag holds it.
That resolves both loose ends at the same time. It also deserves a warning, since
BCD bytes stay below 0x80: scanning for high bytes reports the field as ASCII,
and decoding it as text succeeds and returns punctuation instead of raising.

The rest is sourcing rather than corrections. The UTF-8 point now reads as
correcting the documentation, which does claim ASCII, instead of contradicting it
silently. Rows beyond 1F 06 are marked as read from cards, since the document
only specifies 1F 01 to 1F 06. The surname warning cites the document naming
1F 01 PrimerApellido, and the card I read has both surnames in 1F 01 with
1F 02 zero-length, so that case is real. There is also a note that these
objects are unverified data while EF 711D is not exposed.

One practical warning for anyone going to the source: the TLV tables in the PDF
are images, so pdftotext returns blank gaps where they should be. They have to
be rendered and read as images.

[frankmorgner]

Hmm, the text describes how to parse the output. For users, it would be more helpful to have a tool that actually prints the data in human readable form. Skimming through the documentation, it looks like opensc-asn1 or openssl asn1parse could be used to parse the data...

[nicolasgutierrezdev]

@frankmorgner opensc-asn1 has trouble parsing the data. For instance, MRZs Tag is 7F01, which sets constructed bit and the tool tries to look for nested TLVs, failing decoding. But looking at the OpenSC repo, eidenv seems to have tooling built for BELPIC parsing, maybe we could add support there.