I wrote this ACME proposal for a new challenge method called "emrtd-data-01".
So would want some input on it. Have also sent it to ACME IETF working group, and I plan also to send a rules proposal update to CA/B forum (have applied to entry into CA/B as interested party).
So it would be nice to hear your inputs on it.
Here it is:
what's it stop from someone picked lost passport from airport doing this challenge? it isn't like passports have password keypad
There will be a initial additional validation (for example, biometric face scan via mobile, or athentication via known contact details), which is then linked to passport number AND certificate subject (like domains or emails) AND ACME account URI.
Since issuance of a passport or ID card is a manual process anyways, the user "kickstarts" the authentication by performing a biometric or additional validation to the CA.
By linking it to the account URI (like the dns-persist-01 challenge), the same user can then renew his IV certificate and re-issue it a unlimited number of times during the validity period of the passport or ID card.
Basically, the knowledge of the private key for the account URI used for initial biometric authentication, becomes your "password keypad" to the passport.
I once had same idea but I feel like you have that account itself is enough to be get a renewal already. it still allows reuse subject identity (company/personal name etc) for 398 days.
The idea is that you instead resubmit the passport validation, and thus you are not bound by the 398 days limit.
Instead, its only the biometric or additional (known contact info) validation that is "reused". In this way, the system can allow you to reuse the same supplemental validation for as long as the passport/ID card is valid.
Since the biometric or contact info validation is supplemental (two-factor authentication) the second factor can then be replaced with the ACME account.
There is a TINY risk that both a passport/ID-card AND a account private key gets stolen in the same sweep, but this is to be attributed to a failure of the certificate subject to protect the information.
Snce the validation is also resubmitted for each time validation is performed, the validation method becomes also very privacy friendly, as the CA doesn't need to store any personal data apart from passport number and possibly first/last name, to support renew and reissuance.
These details can even be stored hashed, because the CA only needs to know that the submitted passport is the same as previously submitted.
MRZ/VIZ comparison and NFC reading alone provide limited security. Reading the NFC chip and comparing its contents with the MRZ or VIZ does not by itself prove that the document is genuine, since the data could potentially be copied from another document or extracted from a previous read.
In practice, access to the NFC chip of an electronic Machine Readable Travel Document (eMRTD) requires performing Basic Access Control or Password Authenticated Connection Establishment, which derive session keys from data contained in the document's MRZ or from a Card Access Number (CAN). This means that the MRZ or CAN must be obtained from the physical document before the NFC chip can be accessed.
Authenticity verification of an eMRTD requires validation of the digital signatures contained in the Logical Data Structure (LDS) using the public key infrastructure defined in ICAO Doc 9303. In particular, the Document Security Object MUST be validated to ensure that:
Without validating this trust chain, the authenticity of the eMRTD data cannot be established.
Implementations of the emrtd-data-01 ACME challenge therefore rely on verification of the SOD signature and certificate chain as part of server validation. Access to trusted CSCA certificates is required for this process and is typically obtained through mechanisms such as national trust stores or the Public Key Directory operated by the International Civil Aviation Organization.
Revocation checking for eMRTDs MAY be performed where revocation lists are available, although many issuing states do not publish revocation information for travel documents. Germany is best in class, but others not so much
It should also be noted that the protocol design allows previously read eMRTD data to be submitted, meaning the challenge proves knowledge of the eMRTD data but does not necessarily prove possession of the physical document at the time of validation.
in addition:
Access to protected biometric data on eMRTDs (e.g., fingerprints in DG3 or iris in DG4) requires Extended Access Control (EAC) with authorized inspection system certificates as defined in ICAO Doc 9303; therefore typical consumer NFC readers and ACME clients will generally only be able to access BAC/PACE-protected data groups such as DG1 and DG2.
About the EAC access, thats what I pointed out in the challenge response section. note that theres other DG files accessible by BAC/PACE above DG4, which can be useful in certain validation contexts, like some passports carry registred living adress, which can be used to skip adress validation.
But the section about validation is great, where is that to be inserted? I guess you mean under the "Security considerations" section instead of the simple "relying on the ICAO Doc 9303 PKI infrastructure".
Yes, exactly, Security Considerations would be the right place.
The reason is that it clarifies the practical security model of the protocol. In most deployments using consumer NFC readers, the ACME client will only be able to access data groups available under BAC/PACE (e.g., DG1, DG2 and similar). Biometric data groups such as DG3 (fingerprints) and DG4 (iris) require Extended Access Control (EAC) with authorized inspection system certificates as defined in ICAO Doc 9303.
Because the EAC trust infrastructure and terminal certificates are not publicly distributed, typical ACME clients cannot access those biometric data groups. Knowing the BAC/PACE access parameters (derived from MRZ or CAN) therefore does not grant access to biometric data, since EAC requires additional terminal authentication and chip authentication steps.
Clarifying this in the Security Considerations section helps avoid the assumption that biometric data can be used by this challenge in typical deployments, while still allowing the protocol to make use of other BAC/PACE-accessible DG files where present.
FYI: I've worked with eMRTD implementations and related EU requirements. The comments above are based solely on publicly documented aspects of the ICAO Doc 9303 architecture and operational experience; no restricted material is referenced.
Done, I updated the document now. Did a few small tweaks, for example, instead of referencing to DG1 and DG2, I said "other than DG3 and DG4".
Also the EAC section I putted into privacy as its more of a privacy feature than a security feature, and also clarified in the section that only "face based biometrics can be used".
HOWEVER, a future extension is that,
there is the potential possibility for the CA’s to obtain EAC certificates. Since the CAs are very trusted people, even by governments, it could be possible that ICAO is willing to cross-sign some EAC certificates wth a few of the CA’s in the root trust store (mozilla, microsoft, chrome, apple, etc), opening up the possibility to do initial fingerprint verification using a USB-based table fingerprint reader, entirely inside the ACME protocol.
Here is how this would work:
If ICAO "cross signs" a CA intermediate certificate using their EAC root CA key, it means, that a CA could then use the intermediate certificate (or a leaf certificate signed by it) to authenticate to the chip using EAC.
Technically, it could simply work by the CA having to upload the intermediate certificate to the ICAO's website, along with a challenge nonce signed by the intermediate certificate.
ICAO then cross-signs the intermediate certificate, and gives back the signed version, which the CA can then use to EAC authenticate.
This EAC authentication function would then need to be implemented in a future challenge, like emrtd-data-02 which includes a specific "EAC" challenge function that allows the CA to directly talk to the passport's chip using ACME.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.