TrustManager in Identity Library and UI in Verifier

[keesgeluk]

Fixes #308 partially

• step 1 - TrustManager in the Identity Library
• step 2 - UI support for TrustManager in the Verifier App

Note: the storage of certificates is managed by the TrustManager using the StoreEngine of the Identity Library

• Tests pass

[davidz25]

Hmm. I think we should use the public key as PRIMARY KEY. I think it's entirely possible to have multiple certificates with the same name but different public key (for key rotation, example).

[keesgeluk]

Solved this, using the key identifier in the SubjectKeyIdentifier of the root CA, which should be the same as the key identifier in the AuthorityKeyIdentifier of the issued certificate

[davidz25]

So I thought a little more about this. I think PRIMARY KEY should be on the leaf certificate, not the root. This is because it's entirely possible you could have a PKI like the following

  Some global entitity (e.g. United Nations)
   |
   +---- AAMVA
   |         |
   |         + Maryland
   |         + Arizona
   |         + Georgia
   |         + Massachusetts
   |         [...]
   |
   +---- Austroads
   |         [...]
   |
   +---- EReg
   |         [...]
 [...]

where life is good if you just add the top-level entity. This top-level entity would have e.g. the United Nations flag icon associated with it. In addition to this - mainly for better branding / policy management - you might want to intermediate certificates e.g. AAMVA (for all US/Canada DMVs) or down to a state level. IOW, your verifier app would look something like

trustManager.addCertificate(unCert, Metadata("Jurisdiction recognized by the UN", unLogo))
trustManager.addCertificate(aamvaCert, Metadata("State/province in AAMVA jurisdiction", aamvaLogo))
trustManager.addCertificate(marylandCert, Metadata("State of Maryland (MDOT)", marylandLogo))
trustManager.addCertificate(massachusettsCert, Metadata("Commonwealth of Massachusetts (RMV)", massachusettsLogo))

Let's chat more in our meeting tomorrow about this.

[keesgeluk]

What do you mean by PRIMARY KEY? For not being X509 terminology, I took it like database terminology: the unique identifier of a record. The primary key of a CA certificate could be it's extension SubjectKeyIdentifier, which can be found on the leaf certificate as AuthorityKeyIdentifier ('foreign key'). But in this interpretation I cannot make sense of this statement:

I think PRIMARY KEY should be on the leaf certificate, not the root.

(The identifier of the key that signed the leaf certificate is there as AuthorityKeyIdentifier, the identifier of it's own key is the SubjectKeyIdentifier, but we don't need that to create the trust chain. So what is the property that you have in mind?)

Then, there are two more issues:

1. Do we want also intermediate certificates in the TrustManager? In the mdoc document there is a certificate chain, I supposed it contains everything minus the root certificate. But we can easily add support for that
2. The other issue is the metadata and icons. This has impact also on the UI (for adding and removing certificates). At this moment a user can paste a X509 certificate or browse to a file. If we add this metadata, this will be more complicated. Maybe we can keep it simple...

[davidz25]

By PRIMARY KEY, I mean the piece of data we use in the certificates map in TrustManager:

private val certificates: MutableMap<X500Name, X509Certificate> = mutableMapOf()

Sorry if that wasn't clear.

Do we want also intermediate certificates in the TrustManager?

I think we may want to at least think about what happens if the user registers the example chain above b/c sooner or later that will inadvertently happen. Maybe the right answer is for verify() to return a List<TrustResult> ordered by lenght of path... that way if I use a MA license the result will be {TrustResult_with_MA, TrustResult_with_AAMVA, TrustResult_with_UN}

The other issue is the metadata and icons.

I think we need/want to support this, we need to have at least the holder display this and it would also be nice for the reader... I imagine we can introduce a simple data class with displayName and icon to begin with... include that in TrustResult as an optional data and then modify to take it, like this addCertificate(certificate: X509Certificate, metadata: CertificateMetadata). Not sure CertificateMetadata is the best name but...

[keesgeluk]

As discussed yesterday:

• there is one TrustResult, but the certificate chain will be longer if there are intermediate certificates.
• icons and metadata will be out of scope for now and may be added to the UI part in the future

[davidz25]

Updated the target branch to main.