[ChromeOS] Add strings and UI placeholder for hardware-backed key.

[ChromeOS] Add strings and UI placeholder for hardware-backed key.

BUG=chromium-os:11896, chromium-os:12300, chromium-os:12302
TEST=None. Punt until the underlying support is implemented.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=76755

[mattm, 2011-03-01 22:24:11]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3315: </message>
Should be okay for now, though there is a larger question of how we want to
handle choosing the device to import to on regular Chrome. (crbug.com/70688)

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3318: </message>
I'd prefer if this wasn't hard coded, since on regular Chrome we'd like to be
able to show where a key is stored when using (possibly) multiple hardware
tokens.  Seems we might as well use the same display for both chrome and
chromeos.

I have a todo in there about using multiple columns in the cert manager so we
could have a device column, but I hadn't figured out the html for getting a
multi-column tree. (The model already has the data)

http://codereview.chromium.org/6592079/diff/1/chrome/browser/resources/option...
File chrome/browser/resources/options/certificate_manager.html (right):

http://codereview.chromium.org/6592079/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/certificate_manager.html:85: </if>
Do we actually need this for server certs?  Normally you import just the public
key for a server

[mattm, 2011-03-01 22:26:10]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3314: Import and Bind to Device...
Oh, one other thought, this text is a bit long just wanted to verify whether
this doesn't make the button row too wide to fit on a chromeos screen?

[xiyuan, 2011-03-01 22:48:34]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3314: Import and Bind to Device...
On 2011/03/01 22:26:10, mattm wrote:
> Oh, one other thought, this text is a bit long just wanted to verify whether
> this doesn't make the button row too wide to fit on a chromeos screen?

English fits on chrome os screen and have about 100px on the right end for the
row. But other languages might have problem.

Greg, do we have a shorter name to use for the button?

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3315: </message>
On 2011/03/01 22:24:11, mattm wrote:
> Should be okay for now, though there is a larger question of how we want to
> handle choosing the device to import to on regular Chrome. (crbug.com/70688)

I am not sure about the long term answer either. For R11, we are only thinking
of dealing with the keys backed by ChromeOS device.

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3318: </message>
On 2011/03/01 22:24:11, mattm wrote:
> I'd prefer if this wasn't hard coded, since on regular Chrome we'd like to be
> able to show where a key is stored when using (possibly) multiple hardware
> tokens.  Seems we might as well use the same display for both chrome and
> chromeos.
> 
> I have a todo in there about using multiple columns in the cert manager so we
> could have a device column, but I hadn't figured out the html for getting a
> multi-column tree. (The model already has the data)

What format do you have in your mind?

My string comes from http://crosbug.com/12302. I guess it's because we are only
considering the ChromeOS device backed keys.

http://codereview.chromium.org/6592079/diff/1/chrome/browser/resources/option...
File chrome/browser/resources/options/certificate_manager.html (right):

http://codereview.chromium.org/6592079/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/certificate_manager.html:85: </if>
On 2011/03/01 22:24:11, mattm wrote:
> Do we actually need this for server certs?  Normally you import just the
public
> key for a server

Removed. I am not sure whether we will need this one either.

[mattm, 2011-03-02 02:58:12]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3318: </message>
On 2011/03/01 22:48:34, xiyuan wrote:
> On 2011/03/01 22:24:11, mattm wrote:
> > I'd prefer if this wasn't hard coded, since on regular Chrome we'd like to
be
> > able to show where a key is stored when using (possibly) multiple hardware
> > tokens.  Seems we might as well use the same display for both chrome and
> > chromeos.
> > 
> > I have a todo in there about using multiple columns in the cert manager so
we
> > could have a device column, but I hadn't figured out the html for getting a
> > multi-column tree. (The model already has the data)
> 
> What format do you have in your mind?
> 
> My string comes from http://crosbug.com/12302. I guess it's because we are
only
> considering the ChromeOS device backed keys.

Well, I'd like to just have multiple columns, like "certificate name", "device",
etc  (like in Firefox cert manager).

In that case we wouldn't need a format string in the grd for it.  The cert
manager will already have a string for each cert about what device it's stored
in (it gets this from NSS PK11_GetTokenName function).  In the case of the
chromeos opencryptoki I'm not sure exactly what value it'll return or if you'll
have any control over that, but I guess you could hard code a special case if
you didn't like what it returns for that and there isn't a way to change it.

[xiyuan, 2011-03-02 17:42:31]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3318: </message>
On 2011/03/02 02:58:12, mattm wrote:
> On 2011/03/01 22:48:34, xiyuan wrote:
> > On 2011/03/01 22:24:11, mattm wrote:
> > > I'd prefer if this wasn't hard coded, since on regular Chrome we'd like to
> be
> > > able to show where a key is stored when using (possibly) multiple hardware
> > > tokens.  Seems we might as well use the same display for both chrome and
> > > chromeos.
> > > 
> > > I have a todo in there about using multiple columns in the cert manager so
> we
> > > could have a device column, but I hadn't figured out the html for getting
a
> > > multi-column tree. (The model already has the data)
> > 
> > What format do you have in your mind?
> > 
> > My string comes from http://crosbug.com/12302. I guess it's because we are
> only
> > considering the ChromeOS device backed keys.
> 
> Well, I'd like to just have multiple columns, like "certificate name",
"device",
> etc  (like in Firefox cert manager).
> 
> In that case we wouldn't need a format string in the grd for it.  The cert
> manager will already have a string for each cert about what device it's stored
> in (it gets this from NSS PK11_GetTokenName function).  In the case of the
> chromeos opencryptoki I'm not sure exactly what value it'll return or if
you'll
> have any control over that, but I guess you could hard code a special case if
> you didn't like what it returns for that and there isn't a way to change it.

I understand that multiple columns is the desired way to display such info.

But we are planning to get this ChromeOS device backed keys in R11. And the
current plan (agreed with UI designers) is to just have minimum UI change (i.e.
one import button and this tag suffix for key name). So this format string is
most likely just for R11.

The reason I am putting together this rather empty CL is to get the strings in
before string freeze.

[mattm, 2011-03-02 23:43:12]

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources.grd
File chrome/app/generated_resources.grd (right):

http://codereview.chromium.org/6592079/diff/1/chrome/app/generated_resources....
chrome/app/generated_resources.grd:3318: </message>
On 2011/03/02 17:42:31, xiyuan wrote:
> On 2011/03/02 02:58:12, mattm wrote:
> > On 2011/03/01 22:48:34, xiyuan wrote:
> > > On 2011/03/01 22:24:11, mattm wrote:
> > > > I'd prefer if this wasn't hard coded, since on regular Chrome we'd like
to
> > be
> > > > able to show where a key is stored when using (possibly) multiple
hardware
> > > > tokens.  Seems we might as well use the same display for both chrome and
> > > > chromeos.
> > > > 
> > > > I have a todo in there about using multiple columns in the cert manager
so
> > we
> > > > could have a device column, but I hadn't figured out the html for
getting
> a
> > > > multi-column tree. (The model already has the data)
> > > 
> > > What format do you have in your mind?
> > > 
> > > My string comes from http://crosbug.com/12302. I guess it's because we are
> > only
> > > considering the ChromeOS device backed keys.
> > 
> > Well, I'd like to just have multiple columns, like "certificate name",
> "device",
> > etc  (like in Firefox cert manager).
> > 
> > In that case we wouldn't need a format string in the grd for it.  The cert
> > manager will already have a string for each cert about what device it's
stored
> > in (it gets this from NSS PK11_GetTokenName function).  In the case of the
> > chromeos opencryptoki I'm not sure exactly what value it'll return or if
> you'll
> > have any control over that, but I guess you could hard code a special case
if
> > you didn't like what it returns for that and there isn't a way to change it.
> 
> I understand that multiple columns is the desired way to display such info.
> 
> But we are planning to get this ChromeOS device backed keys in R11. And the
> current plan (agreed with UI designers) is to just have minimum UI change
(i.e.
> one import button and this tag suffix for key name). So this format string is
> most likely just for R11.
> 
> The reason I am putting together this rather empty CL is to get the strings in
> before string freeze.

Sorry, think I misunderstood your previous comment.   

This is okay then, though I think it might be cleaner to have a separate format
and description string  (like "$1 ($2)" format and then a seperate
"hardware-backed" string resource that gets put in $2 for chromeos whereas
chrome could just use the token name from NSS.)

[xiyuan, 2011-03-03 00:23:23]

CL updated to use more generic format for key name with device info per
discussion.

[mattm, 2011-03-03 00:36:06]

Lgtm
On Mar 2, 2011 4:23 PM, <xiyuan@chromium.org> wrote:
> CL updated to use more generic format for key name with device info per
> discussion.
>
> http://codereview.chromium.org/6592079/