[Discussion] Proposal to allow eMRTD/NFC verification and Government Tax Documents for validation
Sebastian Robin Nielsen
I, as a ”interested party” propose to update Section 3.2.3 of the TLS BR, Section 3.2.3 of the S/MIME BR, and Section 3.2.3.1 and 3.2.3.2 of the Code Signing BR to allow the use of ICAO eMRTD data as a high-assurance alternative to manual ID inspection, and also propose to accept tax documents for address validation in TLS and SMIME certificates.
The additions to the BR is marked with a ”+” in the beginning of the line. If your email client supports HTML, you will also see these in green.
Rationale for adding eMRTD verification:
To both enable remote validation of identity, using a passport or eMRTD enabled identity card, but also, to simplify a local check (where a CA verifies the identity over the desk) by allowing a NFC scan and subsequent validation of the CSCA signer keys, to replace the inspection of the physical copy.
This also allows fully automated issuance, without staff of the CA needing to manually verify details, when done remotely, which will drive down the costs of IV certificates.
The rationale to skip biometric check of a customer, at a renew, is that this enables auto renew of personally identified certificates (IV) by using ACME technology.
The eMRTD data must still be submitted and validated. The difference is that only one biometric check is needed as long as no data in the certificate changes.
By linking the biometric identification to both the passport serial number AND the data in a previously issued certificate (Email or domains) or HSM serial it becomes an extremely effective safeguard against passport theft, while IV certificates can be renewed by a ACME client connected to a NFC reader using USB where the passport is placed upon.
I have deliberately chosen not to include a requirement for Active/Chip Authentication (AA/CA). The reason for this is that the issuance of passports or ID cards with these features enabled differs between countries, and even within the same country, depending on current government procurement from different chip manufacturers. For example, the Swedish Police Authority (“Polismyndigheten”) has interchangeably issued documents with and without AA enabled. The risk of chip cloning is effectively mitigated by the mandatory biometric comparison and liveness check.
In addition, in case a future change is made by ICAO, I have pre-prepped with a ruling that allows the CA to use a desktop fingerprint scanner to verify if the DG3 file (EAC access required) is made available to the CA.
I know Entrust have issued the cert to ”icao.int”, but not entirely sure if they have EAC access and would be able to access a passport as ”authorized inspection system” as a CA.
However, changes in ICAO rules may in the future allow CA’s to become authorized inspection systems, especially if CA/B forum rules are updated to allow this type of validation.
The reason to allow eMRTD based authentication for individual verification, is to allow the CA to perform this verification 100% automatically, without any employee of the CA even looking at it. Today the CA/B rules say the CA must verify the document picture for any falsification or alteration even if they received the electronic data and validated the CSCA signature on it, which means a human must approve the issuance in all cases with today’s rules.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Rationale for adding "Government Issued Tax Document" as address validation:
Some people live in apartments or other types of homes where they do not have "authority" over the address.
The "address field" in a certificate is not supposed to indicate that the individual has "authority" over the address, as in owning the deed or having permission from the deed owner.
The only purpose is to verify that the applicant lives at the indicated address.
By allowing a government-issued tax document to be used as address validation, it makes the process much easier for an applicant that
lives on an address they do not have "authority" over, without having to ask the landlord or address owner for permission, while a government issued document is more trustworthy than for example a utility bill.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Root trust:
The root trust for "CSCA validation" is defined as the root trust fetched from ICAO PKD. CA’s in the EU region may also choose to use the EU CSCA Master List as root of trust if they choose so.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
NOTE: This does NOT permit eMRTD based certificate issuance to countries that have a high rate of mis-issuance of identity documents. CA’s must still take resonable steps to blacklist high-risk countries from
eMRTD based certificate issuance in the same way they must address risks of mis-issued identity documents in normal manual issuance with visual comparison.
3.2.3 Authentication of individual identity (TLS and SMIME)
If an Applicant subject to this Section 3.2.3 is a natural person, then the CA SHALL verify the
Applicant’s name, Applicant’s address, and the authenticity of the certificate request.
The CA SHALL verify the Applicant’s name using a legible copy, which discernibly shows the
Applicant’s face, of at least one currently valid government‐issued photo ID (passport, drivers
license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for
any indication of alteration or falsification.
The CA SHALL verify the Applicant’s address using a form of identification that the CA determines
to be reliable, such as a government ID, +[Government-issued Tax document], utility bill, or bank or credit card statement. The CA MAY
rely on the same government‐issued ID that was used to verify the Applicant’s name.
The CA SHALL verify the certificate request with the Applicant using a Reliable Method of
Communication.
+ As an alternative to the procedures in paragraph 2 and 4 above, the CA MAY verify the Applicant's name using electronic data acquired from an eMRTD document as defined by ICAO Doc 9303 scanned by an NFC reader.
+ A CA that uses this method SHALL:
-- + Verify that the electronic data acquired from the eMRTD document is signed with a valid country signer key (CSCA) as defined by ICAO; AND
-- + Verify the eMRTD has not been revoked by checking against a QGIS of revoked passports/IDs where available; AND
-- + Verify the certificate subscriber is in control of the resources indicated in the SANs by using suitable methods described in this BR; AND
-- + Perform a biometric photo comparison between the photo stored in the eMRTD's "DG2" file and a live image of the Applicant, combined with a liveness check to prevent presentation attacks; OR
-- + Verify the certificate request with the Applicant using a Reliable Method of Communication; OR
-- + Verify the applicant in-person, by comparing the picture, acquired from the eMRTD's "DG2" file displayed on a computer screen owned by the CA, with the person applying; OR
-- + Verify the applicants fingerprint, read using a fingerprint scanner, matches the data stored in the ”DG3” file, remotely or in-person.
+Successful validation of the electronic signature on the eMRTD data replaces the requirement to inspect a physical copy for alteration or falsification.
+The CA MAY skip biometric and liveness check, provided the certificate data set (email address or domain names) exactly matches a previous issued
+certificate AND the passport/ID serial number matches the passport/ID serial number used for initial biometric authentication. (renew)
+The CA MAY skip address verification as described in paragraph 3, provided that the CA has received and verified the ”DG11” file with an valid living address.
3.2.3.1 Individual identity verification (Code signing BR)
The CA MUST verify the Applicant’s identity using one of the following processes:
1. The CA MUST obtain a legible copy, which discernibly shows the Certificate Requester’s face,
of at least one currently valid government‐issued photo ID (passport, driver’s license,
military ID, national ID, or equivalent document type). The CA MUST inspect the copy for
any indication of alteration or falsification. The CA MUST also verify the address of the
Certificate Requester using
1. a government‐issued photo ID,
2. a QIIS or QGIS, or
3. an access code to activate the Certificate where the access code was physically mailed to
the Certificate Requester; OR
2. The CA MUST have the Certificate Requester digitally sign the Certificate Request using a
valid personal Certificate that was issued under one of the following adopted standards:
Qualified Certificates issued pursuant to ETSI TS 101 862, IGTF, Adobe Signing Certificate
issued under the AATL or CDS program, the Kantara identity assurance framework at level 2,
NIST SP800‐63 at level 2, or the FBCA CP at Basic or higher assurance.; +OR
+3. The CA MUST have the Certificate Requester scan the eMRTD chip as defined in ICAO Doc 9303
+using a NFC scanner, either in-person or remotely, validate the eMRTD has a valid electronic
+signature by a country signer key (CSCA as defined by ICAO) and then compare the face picture or fingerprint
+as described in 3.2.3.2 point 5, OR ensure the certificate is issued for the exact same hardware serial number of
+the private key protection device as described in 6.2.7.3 and 6.2.7.4. The CA MUST also verify the address of the
+Certificate Requester using
+ 1. a QIIS or QGIS, or
+ 2. an access code to activate the Certificate where the access code was physically mailed to
+the Certificate Requester;
+The CA MAY skip address verification provided that the CA has received and verified the ”DG11” file and it contains a valid living address.
3.2.3.2 Authenticity of Certificate requests for Individual Applicants (Code signing BR)
The CA MUST verify the authenticity of the Certificate Request using one of the following:
1. Having the Certificate Requester provide a photo of the Certificate Requester holding the
submitted government‐issued photo ID where the photo is of sufficient quality to read both
the namelisted on the photo ID and the issuing authority; OR
2. Having the CA perform an in‐person or web camera‐based verification of the Certificate
Requester where an employee or contractor of the CA can see the Certificate Requester,
review the Certificate Requester’s photo ID, and confirm that the Certificate Requester is the
individual identified in the submitted photo ID; OR
3. Having the CA obtain an executed Declaration of Identity of the Certificate Requester that
includes at least one unique biometric identifier (such as a fingerprint or handwritten
signature). The CA MUST confirm the document’s authenticity directly with the Verifying
Person using contact information confirmed with a QIIS or QGIS; OR
4. Verifying that the digital signature used to sign the Request under item (2) of Section 3.2.3.1 is
a valid signature and originated from a Certificate issued at the appropriate level of
assurance as evidenced by the certificate chain. Acceptable verification under this section
includes validation that the Certificate was issued by a CA qualified by the entity responsible
for adopting, enforcing, or maintaining the adopted standard and chains to an intermediate
certificate or root certificate designated as complying with such standard; +OR
+5. Having the CA obtain the electronic information in an eMRTD document using a NFC scanner,
+and then verify that the electronic data acquired from the eMRTD document is signed with a
+valid country signer key (CSCA) as defined by ICAO, and perform a biometric photo comparison
+between the photo stored in the eMRTD's "DG2" file and a live image of the Certificate Requester,
+combined with a liveness check to prevent presentation attacks, or an in-person verification
+of the Certificate Requester compared against a photo shown on a computer screen owned by the CA,
+where the photo is fetched from the "DG2" file inside the eMRTD, or use a fingerprint scanner to compare
+the Certificate Requesters fingerprint with the picture stored in the eMRTD’s ”DG3’ file. The CA MUST
+also verify against a QGIS list of revoked passports/IDs, that the passport/ID has not been revoked, where available.
+The CA may skip biometric and liveness check, provided the certificate is issued to the exact
+same hardware module serial number as described in 6.2.7.3 and 6.2.7.4 as a previous certificate AND
+the eMRTD serial number matches the eMRTD serial number used for initial biometric
+authentication (renew).
Dimitris Zacharopoulos
You might want to start separate discussions for each topic and only in the corresponding WG scope. For example, you cannot discuss code signing issues in the server certificate working group and vice versa. Each WG charter describes the WG's scope 🙂
You may also consider using GitHub to prepare a redline for your proposed changes but, again, separate redline per topic. It will be very difficult to discuss all those issues at the same time.
Best regards,
DZ.
Mar 11, 2026 15:14:20 'Sebastian Robin Nielsen' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/004101dcb193%249d9ca570%24d8d5f050%24%40sebbe.eu.
Sebastian Robin Nielsen
aha I understand. I tought it would be considered ”spammy” to raise ”the same issue” in parallel in every WG. So I sent it to the WG where most of the WG members of the other WG’s are members of.
Maybe certain core topics (like identity verification and similiar that are same/similiar across all BRs) should maybe be lifted out to a ”Core WG”/”Core BR requirements” thing to avoid parallel discussions about the same issue?
That would also make it easier for the whole indistry to make core changes (that should be same regardless of cerificate type) across the board while still keeping TLS, S/MIME, and Code Signing specifics separate.
That would maybe require rearranging the whole structure of the BR so it might be a too big project.
Or would it maybe better to discuss it in a staggered approach? First getting it through servercert-wg, and then when consensus have been reached, then take it through S/MIME and Code Signing. Really didn’t want to piss someone off by sending basically the same email to three groups where basically everyone is member ”cross-group”
Hit me up with the best approach to take this through.
Also, this with ”redline” is something new, do you have a boilerplate or example that I could make use of? I have a github account already so I can eaily create a repo and start uploading there.
Best regards, Sebastian Nielsen
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/541ca072-c9c4-41d1-9f53-dfcf6c61fe01%40harica.gr.