Let's be clear that NDMP, as a standard, is not evolving anymore. The existing NDMP Clients are all backup software, which has not been Sun's business to develop. If we want to involve our OEM backup software vendors in enhanced security extensions to NDMP (this is doable with the right business case) the protocol, wouldn't that still be a different ARC case with requirements on this project, but as a follow-on release?
-- mark Bill Sommerfeld wrote: > On Wed, 2007-08-15 at 11:48 -0700, Alan Wright wrote: > >>> This parameter syntax can only reasonably cope with two mechanisms. >>> while there may only be two at this time, this may not be true forever. >>> If we later support a hypothetical CRAM-SHA256, how do I say I want to >>> allow CRAM-SHA256 and CRAM-MD5 but not plaintext? >>> >> The value can be extended to a list: >> >> ndmp_auth=cram-md5,cram-sha256,... >> > > ok > > >>> that presumes we will never deliver an NDMP client of our own, which >>> seems like a bad assumption. >>> >> Shouldn't we wait until that development happens and consider the >> requirements at that time rather than trying to anticipate them now? >> > > No. The NDMP client project team will argue that it's not their job to > fix the server. > > it is *always* cryptographically suspect to use the same key with > multiple algorithms. *always*. > > - Bill > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070815/b4e5b89d/attachment.html>
