On Fri, 2014-08-22 at 09:52 -0500, Endi Sukma Dewata wrote: > On 8/21/2014 7:18 AM, Simo Sorce wrote: > > On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote: > >> On 13.8.2014 17:20, Endi Sukma Dewata wrote: > >>> 2. Can the UI parse the new key and display it the same way as other > >>> keys that are already saved? That will make it more seamless. > >> Would be nice, but is it worth the effort? We would have to > >> reimplement ipapython.ssh into JavaScript + pull in crypto.js or other > >> lib for sha1and sha256 functions since Web Cryptography API is still > >> only a draft [1]. > > I do not do this lightly, but you have my veto to do any crypto in > > javascript unless you convince me first it make sense. > > > > Simo. > > Just to clarify, the point is to display some kind of information about > the public keys the user just entered in the UI (that have not been > saved) so that: > a) If user enters multiple keys at once, the user can distinguish which > keys have been added rather than displaying a generic "New: key set" for > all new keys. > b) The UI can detect if the key already exists on the server. > If this can be done without any cryptographic operations that would be > great, but I'm not sure about the details. > > For (a) I was wondering if the UI can decode the base-64 encoded public > key entered by the user and display some user-friendly information about > the key itself, maybe just the hexdump of the first few bytes of the > key, or maybe the key type too if possible, or at least just the first > few chars of the undecoded key. > > For (b) the UI would have to use some crypto functions to generate the > key fingerprints as generated by the server. But even if we do that, we > are not doing any data encryption or dealing with secret information.
I do not think you need crypto functions for (a) and it is unclear to me what (b) is, if the key already exist on the IPA server you can find it out with a simple memcmp, why should you need a fingeprint ? > Alternatively, instead of displaying the fingerprints of the saved keys, > the UI can display the first few bytes/chars of hexdump/encoded key to > match (a) such that they can be compared without cryptography. > > BTW, WebCrypto implementation has been making its way into Firefox: > https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing Yes and I find it a particularly bad/dangerous thing, I tend to agree with this: http://tonyarcieri.com/whats-wrong-with-webcrypto see also the links it points to which explains why crypto in javascript (ie in the "user-hostile" sandbox running in the browser) is mostly a bad idea, and can give a false sense of security and a slippery slope in actually unprotecting data. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
