Hi all, I''ve updated the CLI changes that this project is planning to make to the existing zpool/zfs commands.. http://opensolaris.org/os/project/zfs-crypto/phase1/cli-changes/ Comments? thanks, Tony
I don''t like the format of the output from "zfs get keystatus tank/izick" which is inconsistent with other output from "zfs get". Other than that, seems great. -- Ceri This message posted from opensolaris.org
Ceri Davies wrote:> I don''t like the format of the output from "zfs get keystatus tank/izick" which is inconsistent with other output from "zfs get".What would you like to see ? I agree with you that multiple words isn''t correct here we should probably have a defined set of values: available unavailable notdefined and only ever return those strings. -- Darren J Moffat
On Wed, Dec 05, 2007 at 11:27:16AM +0000, Darren J Moffat wrote:> Ceri Davies wrote: >> I don''t like the format of the output from "zfs get keystatus tank/izick" >> which is inconsistent with other output from "zfs get". > > What would you like to see ? > > I agree with you that multiple words isn''t correct here we should probably > have a defined set of values: > available > unavailable > notdefined > > and only ever return those strings.zfs get currently seems to print ''-'' for all other undefined properties: # zfs get origin tank/xvm NAME PROPERTY VALUE SOURCE tank/xvm origin - - Therefore, I''d like to see VALUE print one of ''available'', ''unavailable'' or ''-''. SOURCE might want to read ''-'' in all cases, I''m not really sure. Ceri -- That must be wonderful! I don''t understand it at all. -- Moliere -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20071205/ac147f3f/attachment.bin>
Ceri Davies wrote:> I don''t like the format of the output from "zfs get keystatus > tank/izick" which is inconsistent with other output from "zfs get". > > Other than that, seems great.Thanks for the comments Ceri, I just updated the keystatus property on tuesday and was a bit conflicted as to what to have for the output as well.. Tony
Darren J Moffat wrote:> Ceri Davies wrote: >> I don''t like the format of the output from "zfs get keystatus tank/izick" which is inconsistent with other output from "zfs get". > > What would you like to see ? > > I agree with you that multiple words isn''t correct here we should > probably have a defined set of values: > available > unavailable > notdefined > > and only ever return those strings. >Should do these need to be real words? If compression words into one like "notloaded" is fine, we could just use what we have internally. I had found it not very esthetically pleasing so I hesitated on that.. We could just define them as undefined, notloaded, and loaded. In the same syntax as it is internally... ZIO_CRYPT_KEY_UNDEFINED, /* Wrapping key not defined */ ZIO_CRYPT_KEY_NOTLOADED, /* Key defined, but not loaded */ ZIO_CRYPT_KEY_LOADED /* Key defined and loaded */ Tony
Anthony Scarpino wrote:> Darren J Moffat wrote: >> Ceri Davies wrote: >>> I don''t like the format of the output from "zfs get keystatus >>> tank/izick" which is inconsistent with other output from "zfs get". >> >> What would you like to see ? >> >> I agree with you that multiple words isn''t correct here we should >> probably have a defined set of values: >> available >> unavailable >> notdefined >> >> and only ever return those strings. >> > > Should do these need to be real words? If compression words into one > like "notloaded" is fine, we could just use what we have internally. I > had found it not very esthetically pleasing so I hesitated on that.. We > could just define them as undefined, notloaded, and loaded. In the same > syntax as it is internally... > > ZIO_CRYPT_KEY_UNDEFINED, /* Wrapping key not defined */ > ZIO_CRYPT_KEY_NOTLOADED, /* Key defined, but not loaded */ > ZIO_CRYPT_KEY_LOADED /* Key defined and loaded */For the implementation this would be an integer property and the strings get defined in the mapping table just like we do for the crypto algs etc. loaded vs available notloaded vs unavailable notdefined vs undefined Don''t really care that much, but if we make it this set then we get real words: undefined, available, unavailable That is one from your list and one from mine (well two from mine if you count the inverse ;-)). I thought I was picking the names you had in your code but I guessed wrong :-) -- Darren J Moffat
On Fri, Nov 30, 2007 at 09:29:36AM -0800, Anthony Scarpino wrote:> http://opensolaris.org/os/project/zfs-crypto/phase1/cli-changes/ > > Comments?- Can we s/pwrap/pool/? "pwrap" says too little to me. - Since pools can only have "prwap" keytypes why do we need a keytype property for pools? Do we have plans for new keytypes? (Per-vdev keying, perhaps? Per-object keying?) - "keytype" is confusing. How about "keyed-object"? - "kek" is not very descriptive! s/kek/keyloc/ or s/kek/keylocation/ or s/kek/key-location/ or s/kek/key-URL/ or ... - keystatus should probably be a sub-command, not a property (particularly since it isn''t necessarily a persistent property of a pool or dataset). Nico --
On Wed, Dec 05, 2007 at 06:04:57PM +0000, Darren J Moffat wrote:> Don''t really care that much, but if we make it this set then we get real > words: > > undefined, available, unavailableI prefer real words. I doubt there are localization issues here, but if there were I bet real words would be preferable to made up compound words :)
Nicolas Williams wrote:> On Fri, Nov 30, 2007 at 09:29:36AM -0800, Anthony Scarpino wrote: >> http://opensolaris.org/os/project/zfs-crypto/phase1/cli-changes/ >> >> Comments? > > - Can we s/pwrap/pool/?In my original implementation pwrap and pool were distinct but I think we can now use the string pool here.> "pwrap" says too little to me.agreed.> > - Since pools can only have "prwap" keytypes why do we need a keytype > property for pools? Do we have plans for new keytypes?they don''t have a keytype property only datasets do.> - "keytype" is confusing. How about "keyed-object"?keyed-object is even more confusing to me and implies the wrong thing imo.> > - "kek" is not very descriptive!kek = Key Encryption Key I agree it isn''t the best name.> s/kek/keyloc/ or s/kek/keylocation/ or s/kek/key-location/ or > s/kek/key-URL/ or ...It isn''t a URL though.> - keystatus should probably be a sub-command, not a property > (particularly since it isn''t necessarily a persistent property of a > pool or dataset).It was originally but the ZFS team suggested we change it to a non persistent property to easy scripting. There are already non persistent properties serving a similar function, eg zoned, mounted, (and shared should be there but isn''t at the moment). -- Darren J Moffat
On Wed, Dec 05, 2007 at 06:41:31PM +0000, Darren J Moffat wrote:> Nicolas Williams wrote: > > - Since pools can only have "prwap" keytypes why do we need a keytype > > property for pools? Do we have plans for new keytypes? > > they don''t have a keytype property only datasets do.This: http://opensolaris.org/os/project/zfs-crypto/phase1/cli-changes/#New_zfs_zpool_properties implies otherwise: " New zfs/zpool properties There are 3 new properties created ... * keytype ? the key method used in the pool or dataset; in other words, how the kek is to be used. o There are two string values, ''pwrap'' and ''dataset'' "> > - "keytype" is confusing. How about "keyed-object"? > > keyed-object is even more confusing to me and implies the wrong thing imo.Any other ideas?> > > > - "kek" is not very descriptive! > > kek = Key Encryption Key > > I agree it isn''t the best name.What is it meant to mean?> > s/kek/keyloc/ or s/kek/keylocation/ or s/kek/key-location/ or > > s/kek/key-URL/ or ... > > It isn''t a URL though.The ellipsis was an invitation to you to offer better suggestions :) s/kek/key/?> > - keystatus should probably be a sub-command, not a property > > (particularly since it isn''t necessarily a persistent property of a > > pool or dataset). > > It was originally but the ZFS team suggested we change it to a non > persistent property to easy scripting. > > There are already non persistent properties serving a similar function, > eg zoned, mounted, (and shared should be there but isn''t at the moment).I see. Thanks! Nico --
Nicolas Williams wrote:> On Wed, Dec 05, 2007 at 06:41:31PM +0000, Darren J Moffat wrote: >> Nicolas Williams wrote: >>> - Since pools can only have "prwap" keytypes why do we need a keytype >>> property for pools? Do we have plans for new keytypes? >> they don''t have a keytype property only datasets do. > > This: > > http://opensolaris.org/os/project/zfs-crypto/phase1/cli-changes/#New_zfs_zpool_properties > > implies otherwise: > > " > New zfs/zpool properties > > There are 3 new properties created > > ... > > * keytype ? the key method used in the pool or dataset; in > other words, how the kek is to be used. > o There are two string values, ''pwrap'' and ''dataset'' > " >Originally there was two keytypes for pools.. Now there is one.. My impression was we were keeping the property for future expansion given and its only current value was ''pwrap''.> >>> - "keytype" is confusing. How about "keyed-object"? >> keyed-object is even more confusing to me and implies the wrong thing imo. > > Any other ideas?I don''t see this as confusing.. it''s the type of keying used.. the key is either stored as a pwrap (or maybe pool now) or as dataset.> >>> - "kek" is not very descriptive! >> kek = Key Encryption Key >> >> I agree it isn''t the best name. > > What is it meant to mean? >the key that wraps the dataset key. I thought about ''wrappingkey'' or ''wrapkey'' a while back. There is some value to it not being a commonly used name by forces people to learn what it is before using it.>>> s/kek/keyloc/ or s/kek/keylocation/ or s/kek/key-location/ or >>> s/kek/key-URL/ or ... >> It isn''t a URL though. > > The ellipsis was an invitation to you to offer better suggestions :) > > s/kek/key/?key doesn''t work because it gives the impression it''s the key to the dataset and it isn''t it''s just the wrapping key to the dataset key.> >>> - keystatus should probably be a sub-command, not a property >>> (particularly since it isn''t necessarily a persistent property of a >>> pool or dataset). >> It was originally but the ZFS team suggested we change it to a non >> persistent property to easy scripting. >> >> There are already non persistent properties serving a similar function, >> eg zoned, mounted, (and shared should be there but isn''t at the moment). > > I see. Thanks! > > Nico
Darren J Moffat wrote:> Anthony Scarpino wrote: >> Darren J Moffat wrote: >>> Ceri Davies wrote: >>>> I don''t like the format of the output from "zfs get keystatus >>>> tank/izick" which is inconsistent with other output from "zfs get". >>> What would you like to see ? >>> >>> I agree with you that multiple words isn''t correct here we should >>> probably have a defined set of values: >>> available >>> unavailable >>> notdefined >>> >>> and only ever return those strings. >>> >> Should do these need to be real words? If compression words into one >> like "notloaded" is fine, we could just use what we have internally. I >> had found it not very esthetically pleasing so I hesitated on that.. We >> could just define them as undefined, notloaded, and loaded. In the same >> syntax as it is internally... >> >> ZIO_CRYPT_KEY_UNDEFINED, /* Wrapping key not defined */ >> ZIO_CRYPT_KEY_NOTLOADED, /* Key defined, but not loaded */ >> ZIO_CRYPT_KEY_LOADED /* Key defined and loaded */ > > For the implementation this would be an integer property and the strings > get defined in the mapping table just like we do for the crypto algs etc. > > loaded vs available > notloaded vs unavailable > notdefined vs undefined > > Don''t really care that much, but if we make it this set then we get real > words: > > undefined, available, unavailable > > That is one from your list and one from mine (well two from mine if you > count the inverse ;-)). > > I thought I was picking the names you had in your code but I guessed > wrong :-) >Yeah I know at the time you liked my wording for the enum, but we weren''t talking about external names.. :) Either way I don''t care too much.. I''m happy with having undefined, available, and unavailable as the external words.. if we change the internal to match or not isn''t a big deal. Tony
On Wed, Dec 05, 2007 at 01:30:47PM -0800, Anthony Scarpino wrote:> Nicolas Williams wrote: > > New zfs/zpool properties > > > > There are 3 new properties created > > > > ... > > > > * keytype ? the key method used in the pool or dataset; in > > other words, how the kek is to be used. > > o There are two string values, ''pwrap'' and ''dataset'' > >" > > Originally there was two keytypes for pools.. Now there is one.. My > impression was we were keeping the property for future expansion given > and its only current value was ''pwrap''.Hmmm, don''t do that -- if there''s no need for that property now then don''t provide it.> > > >>>- "keytype" is confusing. How about "keyed-object"? > >>keyed-object is even more confusing to me and implies the wrong thing imo. > > > >Any other ideas? > > I don''t see this as confusing.. it''s the type of keying used.. the key > is either stored as a pwrap (or maybe pool now) or as dataset.I do -- it makes me think "cipher and mode".> > > >>>- "kek" is not very descriptive! > >>kek = Key Encryption Key > >> > >>I agree it isn''t the best name. > > > >What is it meant to mean? > > > > the key that wraps the dataset key.So kwk?> I thought about ''wrappingkey'' or ''wrapkey'' a while back. There is some > value to it not being a commonly used name by forces people to learn > what it is before using it.I think I prefer wrapkey. For one, it''s not an acronym. For two, "key encryption key" is not necessarily obvious. "Wrapping key" or "key wrapping key" is more obvious (to me). ("Encryption" alone can mean lots of things, from the application of a raw cipher to the application of a confidentiality+integrity protection cipher mode. "Wrap" is much more clear to me in the context of keys. But perhaps I''m just hanging around crypto too much and not seeing it from the p.o.v. of someone who''s a complete crypto newbie.)
Nicolas Williams wrote:> On Wed, Dec 05, 2007 at 01:30:47PM -0800, Anthony Scarpino wrote: >> Nicolas Williams wrote: >>> New zfs/zpool properties >>> >>> There are 3 new properties created >>> >>> ... >>> >>> * keytype ? the key method used in the pool or dataset; in >>> other words, how the kek is to be used. >>> o There are two string values, ''pwrap'' and ''dataset'' >>> " >> Originally there was two keytypes for pools.. Now there is one.. My >> impression was we were keeping the property for future expansion given >> and its only current value was ''pwrap''. > > Hmmm, don''t do that -- if there''s no need for that property now then > don''t provide it. > >>>>> - "keytype" is confusing. How about "keyed-object"? >>>> keyed-object is even more confusing to me and implies the wrong thing imo. >>> Any other ideas? >> I don''t see this as confusing.. it''s the type of keying used.. the key >> is either stored as a pwrap (or maybe pool now) or as dataset. > > I do -- it makes me think "cipher and mode".It could mean that in the future too, phase 1 just has one cipher and mode.. other phases could bring others.. See, it''s a perfect fit! :)> >>>>> - "kek" is not very descriptive! >>>> kek = Key Encryption Key >>>> >>>> I agree it isn''t the best name. >>> What is it meant to mean? >>> >> the key that wraps the dataset key. > > So kwk? > >> I thought about ''wrappingkey'' or ''wrapkey'' a while back. There is some >> value to it not being a commonly used name by forces people to learn >> what it is before using it. > > I think I prefer wrapkey. For one, it''s not an acronym. For two, "key > encryption key" is not necessarily obvious. "Wrapping key" or "key > wrapping key" is more obvious (to me). ("Encryption" alone can mean > lots of things, from the application of a raw cipher to the application > of a confidentiality+integrity protection cipher mode. "Wrap" is much > more clear to me in the context of keys. But perhaps I''m just hanging > around crypto too much and not seeing it from the p.o.v. of someone > who''s a complete crypto newbie.) >
On Wed, Dec 05, 2007 at 02:19:44PM -0800, Anthony Scarpino wrote:> >>I don''t see this as confusing.. it''s the type of keying used.. the key > >>is either stored as a pwrap (or maybe pool now) or as dataset. > > > >I do -- it makes me think "cipher and mode". > > It could mean that in the future too, phase 1 just has one cipher and > mode.. other phases could bring others.. See, it''s a perfect fit! :)That''s conflating different things -- one is "at what level are we doing crypto (per-pool, per-vdev, per-dataset, per-object)" and the other is "cipher and mode". Those are very different things. You might want to use different ciphers/modes in different pools/vdev/ datasets/objects, but I don''t think you''d want to say that in the same property where you say where you do the crypto. Right?
Nicolas Williams wrote:> On Wed, Dec 05, 2007 at 02:19:44PM -0800, Anthony Scarpino wrote: >>>> I don''t see this as confusing.. it''s the type of keying used.. the key >>>> is either stored as a pwrap (or maybe pool now) or as dataset. >>> I do -- it makes me think "cipher and mode". >> It could mean that in the future too, phase 1 just has one cipher and >> mode.. other phases could bring others.. See, it''s a perfect fit! :) > > That''s conflating different things -- one is "at what level are we doing > crypto (per-pool, per-vdev, per-dataset, per-object)" and the other is > "cipher and mode". Those are very different things. > > You might want to use different ciphers/modes in different pools/vdev/ > datasets/objects, but I don''t think you''d want to say that in the same > property where you say where you do the crypto. Right? >The keytype is just for the kek and the way the kek is stored. There is nothing else to it.. Currently it support all of one algorithm to store this kek.. If we add another mode it''s just another mode for the keytype property.. It''s not that complicated.. I think you''re overloading the meaning of keytype too much.. it''s suppose to be simple.. not IPsec :) This is also completely different from the storage of the actual data in the dataset you realize.. that''s the ''encryption'' property.. Tony