On Tue, Feb 25, 2025 at 11:26 AM Robert Moskowitz <r...@htt-consult.com> wrote: > > On 2/25/25 10:56, Jeffrey Walton wrote: > > On Tue, Feb 25, 2025 at 10:46 AM Robert Moskowitz <r...@htt-consult.com> > > wrote: > >> On 2/25/25 10:41, Tim via users wrote: > >> > >> On Tue, 2025-02-25 at 09:08 -0500, Robert Moskowitz wrote: > >> > >> I do wonder how it will "know" that I have the QR in front of the camera > >> and it is in proper focus... > >> > >> I imagine it's relying on the camera to focus itself. And as soon as > >> it recognises an image (sees QR data in it), it would act. > >> > >> That's pretty much how it behaves on phones, you aim and it acts as > >> soon as it sees what it can use. There's no waiting for a user to > >> click a button (which could be a right pain if you were trying to > >> single out *ONE* QR out of a bunch that are near each other and hadn't > >> yet framed things the way you wanted). > >> > >> that is pretty much what I am "seeing". > >> > >> I added the --nodisplay option and now I can watch the capture stream to > >> sysout in my command window, but I don't see where I can get it to > >> terminate after scanning a single code. > > From what I understand about QR codes and custom protocol handlers, > > the scanned code should be something like (contrived): > > > > pem://<cert> > > > > or: > > > > csr://<cert request> > > > > The "pem://" or "csr://" part allows the camera software to invoke the > > proper protocol handler, like "https://"; does for a QR-encoded url. > > > > What are you trying to do with the request once it is decoded? > > A human, operating the root CA that was taken out of the vault, and > while being videoed, reviews the CSR before running the scripts to sign > the Intermediate level CA key. The resultant cert is then displayed > itself as a QR code (qrencode) that can then be moved as needed.
It sounds like (to me) the QR code is the wrong tool for the job. You don't need to package a CSR in a QR code, and you don't need to encode the resultant certificate in a QR code. > This way, no security tapes are taken off any digital ports and our > tamper evidence proof is a lot simpler. > > Well the tape was taken off the camera and a new one put on before > returning to the vault, but the risk via camera is way down from the > risk of an open USB port. > > I "just" want that PEM file... Stop dicking around with QR codes. PEM files are text files. They are easy to handle. > I can create a low-cost PKI approach that is tamper evident. Not that > $200,000/2yr tamper resistant approach being foisted on our avionics work. > > You should see what ICAO has set up for passport PKI key signing. It > only took them ~3 years to get in up and running. It kind of runs. Yes > I did get a tour and they are quite proud of what they have done... > > And for some countries, they do NOT invite them to Montreal. They build > the whole system, do the signing and have everything securely shipped to > said country. Some places just don't have the human resources to move > to the new passport system (one island nation only has 15? people for > their whole Civil Aviation Authority! Including tower control!). Jeff -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
