> On Wed, 26 Mar 2003, Anders Reed Mohn wrote: > > > >I appreciate the various replies that I've received. However, > > >the fundamental question of what defines encryption, so far as > > >SB1386 is concerned, is still unanswered. I've looked through > > >other California State Bills and supporting documentation, all > > >to no avail. > > > How does California Law relate to the US justice department > > anyway? If your lawmen don't know any California precedence (if > > that's the word), then I assume a definition from some federal > > bureau/office is "next in line" to be valid.
On 28 Mar 2003, at 7:25, Cliff Gilley (System Admin, HolyElvis.com wrote: > ...In this situation, the legislature has completely failed to > provide a definition of the term "encryption". If a case is > brought under this law, I can guarantee you that both sides will > be arguing what encryption is, and it's likely going to take an > appellate court's decision to impute a definition to the Senate's > bill. It would have been much simpler (and cheaper for CA > taxpayers) for everyone involved if the Senate had done its job > and provided a definition under the bill for a technically > amorphous term. Then you might argue that their definition was > insufficient or inaccurate, but at least you'd know what you had > to do. > > Here's the unfortunate part, at least for consumers. When a term > has plain meaning (like "encryption"), and the legislature has > not specified a separate meaning, the courts will probably apply > the term's plain meaning. Which in this case is completely > contradictory to the intent of the law - someone *could* use > ROT-3 "encryption" and fit within the words of the statute, if > not the spirit. This is a really tough legal question, which is > probably the reason the Senate passed on addressing it. > bhh>>> Actually, I feel that the Senate was, probably unwittingly, wise in not defining the term encryption. My reasoning for this is simple, encryption is an ever evolving term tied to the current state-of-art and best practices. What we define as encryption yesterday, today and in the future was, is, and could be different. By not defining the term Encryption in law, the court need only consider the scope and objectives of the application (requirements and specifications), current state-of-art, and current best practices to qualify and define the term for a particular matter before it. More importantly, we should not try to use ubiquitous and ambiguous terms such as encryption to define what is a simple requirement, i.e., prevent unauthorized access to personally identifiable information. Furthermore, by not providing a legal definition of the term encryption, the parties of interest have the burden to sufficiently document security requirements, specifications and limitations. Consequently, vendors will be required to establish and document system security engineering processes that are sate-of-art, verifiable and satisfy best practices. Its time for businesses, software and systems vendors to get serious and put honest thought into security. One size does not fit all, and effective solutions do not come in a box. A well thought out security engineering process is the keystone of the arch of a quantifiable and qualifiable security solution. bhh<<< - - **************************************************** Bernie Chief Technology Architect Chief Security Officer [EMAIL PROTECTED] Euclidean Systems, Inc. ******************************************************* // "There is no expedient to which a man will not go // to avoid the pure labor of honest thinking." // Honest thought, the real business capital. // Observe> Think> Plan> Think> Do> Think> ******************************************************* _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html