The external provider uses the selectionArgs parameter in a non-standard
way, so it doesn't make sense to pass selection to the query
independently. Also enabling strict mode here, to nail down the fields
that can be requested to the contract of the provider.
- updated regex
- added error if server does not implement hkp function
- added algorithm extraction from downloaded key if hkp fails
-- fixes algorithm shown unknown if hkp response field is empty
Firefox for Android requires `mimeType` condition on the intent filter.
Built-in browsers (e.g. Chrome) need an intent filter that will *not* have
`mimeType` conditions.
Using two common MIME types: `application/octet-stream` is mentioned in
the I-D and `application/pgp-keys` is a common type for keys used in the
wild.
Some hosts (like `kernel.org`) redirect all requests to a subdomain (in
this case `www`). As WKD queries are always over HTTPS following redirects
would be safe.
This change extends WKD support for direct Web Key Directory URLs
similarily to Facebook key URLs and HKP URLs.
When a link with scheme `https` and path starting with
`/.well-known/openpgpkey/hu/` is clicked Android will suggest importing
the key with OpenKeychain.
Fixes#2270.
Moves `toWebKeyDirectoryURL` to a separate class adding unit tests
for URL correctness as well as support for spaces at the beginning
and end of the e-mail. Spaces are frequently automatically inserted
by soft keyboards.
This change allows importing keys from NDEF tags that have fingerprint
encoded as an `openpgp4fpr` URI when the application is in background.
After scanning a tag the `Import keys` activity is shown with results of
the search for key fingerprint encoded in the tag.
If a search pattern that looks like an email address is found
an additional query using Web Key Directory will be performed.
Implements basic flow described in "Key Discovery" [0] I-D.
Querying SRV records is not supported.
Fixes partially #2270.
[0]: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05#section-3.1
Currently QR scanner supports only `openpgp4fpr` URIs. VCard specification
allows embedding public key information as an URI in `KEY` field [0]. Two
schemes used with this field - `https` and `data` are either insecure or
not practical [1]. As the value of `KEY` field is a URI one can use
`openpgp4fpr` URI there to have both secure and small links.
This change will extract URI from `KEY` field from a scanned VCard and
process it just like it would be a URI scanned directly. When a `openpgp4fpr`
URI is put there the UI would search and import the key and show the confirm
dialog.
Example VCard with this URI:
BEGIN:VCARD
FN:Test WKD
EMAIL:test-wkd@metacode.biz
KEY:OPENPGP4FPR:74EC8D3DA82A79DAA25DF10C6BA55ED83ABAE1BB
END:VCARD
[0]: https://tools.ietf.org/html/rfc6350#section-6.8.1
[1]: https://www.av8n.com/computer/htm/distributing-keys.htm#sec-fing
