On 18 Sep 2013 07:44, "Christoph Gruber" <gr...@guru.at> wrote: > > On 2013-09-17 Max Kington <mking...@webhanger.com> wrote: > > > [snip] > > Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. > [snip] > > I would tend to agree for environments with very high regulations, where the need to comply with regulations is more important than the need to keep data confidential. > I would suggest to balance that for every organisation. The risk to disclosure is much higher if data is stored unprotected. Any admin with access to the file system is able to read it. > Maybe this could be a cultural difference between US and Europe, the regulative pressure in US is higher, in Europe the privacy is more important or more protected. > I agree that both ways may be the right implementation for an organisation, but this has to be a management decision, balancing the needs.
I was referring to the UK :-) I'm not saying it isn't important to consider how data is made available in the cases where you have end to end security but a future standard wants to be permissive of a solution even if it's out of scope for the RFC rather than prohibitive by including it as mandatory, could/can vs should/must. That said now there appears to be evidence that side channel attacks that force lesser security where it's an option are being actively exploited. Previously we'd have all assumed that the main benefit of those was in interoperability but now not so much. So there is an argument to use 'must' more in standards concerning security. By making archival a separate concern you also reduce the complexity of many deployments. As you say, for environments with very high regulation, my personal mailbox, isn't, my work one, is. Max > > Best regards > > -- > Christoph Gruber > "If privacy is outlawed, only outlaws will have privacy." Phil Zimmermann >
_______________________________________________ The cryptography mailing list email@example.com http://www.metzdowd.com/mailman/listinfo/cryptography