[<prev] [next>] [day] [month] [year] [list]
Message-ID: <3E8B4F06.20328.3FE275@localhost>
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