So the manufacturer provides a number on a label that can be verified to have been written by them that is unique and unguessable for each label printing.
We provide a program to generate these labels and a PWA to verify the labels. We’d need to serve the PWA on the Internet, and the label generator source code. A Go program can host the PWA and Go can be the language for the label generator. We’d need to localize/translate the PWA and maybe the label generator. I’m not familiar with non-english processors and operating systems around the world. I’m concerned that Go is supported only for the big server ones for english speakers which may be different than at printing stations, but maybe we are just dealing with Windows and Linux on x86 processors generally. By having the URL for the manufacturer’s public key in the label we don’t have to track a list of manufacturers. The manufacturer follows our specification for a verification server and label inputs. They track their UUIDs and keys and we handle the ECDSA decryption logic and let them say yes/no to the decrypted UUID. I may be misunderstanding how ECDSA would be used. My previous train of thought was based on wanting to have complete control over the consumer experience. By relying on manufacturers’ servers the same implementation is repeated and could be done incorrectly, and there could be downtime. Distributors are an important part of the supply chain and they do open medication packaging necessarily. Pharmacies often repackage medication. Untrustworthy pharmacies could get trusted packaging, and untrustworthy pharmacies seem to be the biggest problem stated by the report. Matt On Tuesday, December 26, 2017 at 4:36:25 PM UTC-6, Tamás Gulácsi wrote: > > > > 2017. december 26., kedd 21:59:17 UTC+1 időpontban Frank Davidson a > következőt írta: >> >> I was thinking a Progressive Web App (PWA) to avoid writing multiple >> Android, Web, iOS apps... I know QR codes are more broadly used but I'm not >> sure if they can store the amount of info we would need? I think you need >> 384 bits plus the data we need to encode for secure ECDSA? Aztec codes seem >> to be used somewhat ubiquitously and seem also to be able to store a good >> amount more data than QR. Building a PWA using Aztec codes for end users, >> we might be able to use the JS port of Zxing: >> https://github.com/LazarSoft/jsqrcode >> >> > > http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx > > QR code: 4296 alpha, 7089 numeric characters > Aztec: 3067 alphanumeric, 3832 numeric, 1914 Bytes > > so no real limitations here. > > If the URL in the Aztec code designates a landing page on the >> manufacturer's certified domain, that end point can deliver up the correct >> public key, and since that is used to verify the signature, and a man in >> the middle attack is prevented by the manufacturer's domain's cert, I think >> we'd be done. I'm thinking we may not even need a server as the domain's >> certificate from a valid CA would serve this purpose. >> >> Thoughts? >> > > Yes, the app could download the public key from the _central authority_ - > you have to provide a certificate authority which signs the private keys, > to forbid > anybody to serve its own Aztec codes with a a vanilla public key. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
