On 8/22/2014 12:18 PM, Petr Vobornik wrote:
On 22.8.2014 17:51, Simo Sorce wrote:
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 ?
in both (a) and (b) the key does not exist on the server - user just
added the key(s) but he had not yet clicked on 'update' button to
upload them.
Right, all the UI has is the base-64 encoded key entered by the user. So
without crypto, all the UI can do is probably decoding the key and, if
possible, parsing the key structure to obtain some useful information.
Can we obtain the key type this way, or does it require crypto?
The existing keys on the other hand are displayed in the UI with their
fingerprints and key type, for example:
A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa)
The UI does not show the base-64 encoded key unless the user clicks the
"Show/Set key" button.
To check if a new key already exists on the server, the UI can compare
either the base-64 encoded keys or the fingerprints (if available).
Will displaying of the fingerprints prior saving help(improve UX) the
user? The issue is that user can't distinguish multiple added keys.
The "first few chars of the undecoded key" variant of (a) will solve
the issue in the most efficient way - user will see what he just
added. No crypto needed.
Displaying the fingerprints of the new keys is not necessary to solve
(a), but the display will not be seamless without it. For example, it
could become like this:
A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa)
AAAAB3NzaC1yc2EAAAABIwAAAQEAueevoxw+... (new key)
On the other hand, since existing keys are displayed with their
fingerprints, it's not possible to open a public key file and compare it
to the list before adding it to the UI.
Are the fingerprints actually only used internally by the server? Do the
users have any use of the fingerprints? If the fingerprints are internal
only, the UI shouldn't need to display it. I'd say the UI should just
display the key itself, not the whole key but just long enough to be
distinguishable, either as a hexdump or base-64 encoded.
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.
If for some reason we decided to generate fingerprints in the UI, in my
opinion using WebCrypto will not pose any security problem or mislead
users into a false sense of security because the operation is purely
informational, it does not do any encryption/decryption/validation. Any
fingerprint generated on the UI side will be discarded anyway, the
server will still generate its own fingerprints.
This belongs to a separate discussion, but the article was concerned
about possible inconsistencies across browser implementations and the
reliance on the server to deliver the application that uses WebCrypto. I
think there are limited/specific scenarios where WebCrypto could be used
in IPA (like above) as long as the implications are well understood. In
the future we might be able to deliver the whole UI as a signed browser
extension that uses WebCrypto which would address those concerns.
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
