From: cta at hcsin.net (Bernie, CTA)
Subject: Re: California State Bill SB1386

> 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
cta@...in.net
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>      
*******************************************************

Powered by blists - more mailing lists