<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Mike,<br>
<br>
Let me address just a few of these, to start....</p>
<p>THE SECURITYAUDIT CLASS = assuming you mean logging? We almost
always call these abstractions "Logger" in the programming world....<br>
<br>
THE CRYPTOGRAPHICSUPPORT CLASS = We call this ESAPI.encryptor()<br>
<br>
THE IDENTIFICATIONANDAUTHENTICATION CLASS = ESAPI.authenticator()</p>
<p>THE SECURITYMANAGEMENT CLASS = ????????<br>
<br>
VERIFICATION PARAMETERS CLASSES = is a entirely separate conversation
altogether, and implies a very specific kind of data and data
validation architecture.. Do you have a moment to describe this part of
your proposal in a bit more depth, sir?<br>
<br>
- Jim</p>
<br>
<blockquote
 cite="mid:21D3693DA55EF14BB72DCC18FB65B29109296D8F@ASHBMBX04.resource.ds.bah.com"
 type="cite">
  <pre wrap="">Something provider-like that could for example be easily implemented using PHP. Not proposing shoehorn ESAPI into JCE framework.

E.g. take the JCE spec and bend it for our purposes to look something something like:

THE PROVIDER CLASS
      How Provider Implementations Are Requested and Supplied
      Installing Providers
THE SECURITYAUDIT CLASS
THE CRYPTOGRAPHICSUPPORT CLASS
THE IDENTIFICATIONANDAUTHENTICATION CLASS
THE SECURITYMANAGEMENT CLASS
THE APPLICATIONDATA CLASS &lt;-- verification parameters below would be associated with this class
VERIFICATION PARAMETERS CLASSES
      Verification Parameter Specification Interfaces and Classes
            The VerificationParameterSpec Interface
            The PositiveValidationParameterSpec Class
            The MySQLEscapingParameterSpec Class &lt;-- parameters = data policy, not just input validation
            ...
      The VerificationParameters Class
      The VerificationParameterGenerator Class
      Pattern Interfaces
      Pattern Specification Interfaces and Classes
            The PatternSpec Interface
                  The DateSpec Class
                  The InputSpec Class
                  The NumberSpec Class
                  The FileNameSpec Class
                  The ValidRedirectLocationSpec Class
                  ...
      The PatternFactory Class
      The ValidatedDataGenerator Class
      The EscapedDataGenerator Class
      Pattern Management
            Patternstore Location
            Patternstore Implementation
           The PatternStore Class

Mike B.

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owasp-esapi-bounces@lists.owasp.org">owasp-esapi-bounces@lists.owasp.org</a> [<a class="moz-txt-link-freetext" href="mailto:owasp-esapi-bounces@lists.owasp.org">mailto:owasp-esapi-bounces@lists.owasp.org</a>] On Behalf Of Kevin W. Wall
Sent: Wednesday, August 12, 2009 8:25 PM
To: Rogan Dawes
Cc: <a class="moz-txt-link-abbreviated" href="mailto:owasp-esapi@lists.owasp.org">owasp-esapi@lists.owasp.org</a>
Subject: Re: [OWASP-ESAPI] Question about Provider/Implementation architecture

Rogan Dawes wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Jim Manico wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">And for what it's worth, I think it would be rather easy to do. We 
just need a master interface that excapsultates the functionality of 
the sub-providers that we already have, and then support...

*ESAPI.addProvider(new com.your.company.ESAPI());*

Then when you implement *com.your.company.ESAPI* it will have to implement the master ESAPI interface....
      </pre>
    </blockquote>
    <pre wrap="">How is this different to (better than) the current:

ESAPI.setEncoder(new com.yourcompany.Encoder());

for the bits you actually want to implement yourself?

all addProvider would do is:

public void addProvider(Provider provider) {
    setEncoder(provider.encoder());
    ...
}

but provider would have to have implementations for EVERY ESAPI 
interface, even those where you just want to use the reference.

Doesn't seem like an improvement to me.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Before I make a judgment, I'd like a clarification as to what *exactly* Jim is referring to. Specifically Jim, are you referring to is a provider that conforms to java.security.Provider or something simply "provider-like"?

Recognize that java.security.Provider requires some very specific expectations (see
<a class="moz-txt-link-freetext" href="http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Provider">http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Provider</a>)
In particular, there is some expectation of providing an SPI (service provider interface). And then there's the question does it need to integrate in with the rest of the Java security providers? E.g., 1 reqt, as per the above URL:
------------------------------------------------------------------------
    static EngineClassName getInstance(String algorithm)
        throws NoSuchAlgorithmException

    static EngineClassName getInstance(String algorithm, String provider)
        throws NoSuchAlgorithmException, NoSuchProviderException

    static EngineClassName getInstance(String algorithm, Provider provider)
        throws NoSuchAlgorithmException

where EngineClassName is the desired engine type (MessageDigest/Cipher/etc). For
example:

    MessageDigest md = MessageDigest.getInstance("MD5");
    KeyAgreement ka = KeyAgreement.getInstance("DH", "SunJCE");

return an instance of the "MD5" MessageDigest and "DH" KeyAgreement objects, respectively.
------------------------------------------------------------------------

Furthermore, I think the intent of providers is somewhat different. If you are providing a Provider (sorry) implementation, you generally are expected to provide EVERYTHING needed and not just selectively (say) writing a single piece such as (for ESAPI) an Encryptor or a Validator. In that sense, I agree with Rogan. I think very few are going to be willing to do that. Unless ESAPI is successful beyond our wildest dreams, we are not going to get the ESAPI equivalents to providers that JCE did (Bouncy Castle, Cryptix, IAIK, etc.). A large part of the reason that they were so successful is that 1) Sun provided a rather skimpy set of crypto algorithms, 2) the Sun implementation was not originally open source, and 3) the US export restrictions at the time were quite draconian. Those things together drove the open source community to provide numerous implementations of Sun's JCE. (That plus Sun
*did* define an SPI as well.)

Also, if Jim means "provider" in the sense of java.security.Provider, note that java.security.Provider
        "class represents a 'provider' for the Java Security API, where
        a provider implements some or all parts of Java Security."

As far as that goes, I would argue that what OWASP is doing with ESAPI is not so much _Java_ security as _Application_ security. That is not to say that much of this is lacking from the JDK. It is, but I don't think that's how Li Gong envisioned _Java_ security and its whole security model.

Now if Jim is referring "provider" as simply a way to repackage and/or re-factor things to make it so the ESAPI reference model is easier to replace with one's own implementation, I can _ALMOST_ support that.
(I already support it in principal, but you all know the difference between theory and practice. :) I *would* have a problem is implementing one's own ESAPI "provider" meant replacing the whole reference model though. I just don't see the value in that (unless we have the incentive to do a crappy job, but obviously that's NOT the case).

Anyhow, those are my thoughts. Perhaps if Jim or Mike Boberski could give me a bit more context and perspective I'd be able to make more rational arguments.

-kevin
--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
_______________________________________________
OWASP-ESAPI mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OWASP-ESAPI@lists.owasp.org">OWASP-ESAPI@lists.owasp.org</a>
<a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-esapi">https://lists.owasp.org/mailman/listinfo/owasp-esapi</a>
_______________________________________________
OWASP-ESAPI mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OWASP-ESAPI@lists.owasp.org">OWASP-ESAPI@lists.owasp.org</a>
<a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-esapi">https://lists.owasp.org/mailman/listinfo/owasp-esapi</a>
  </pre>
</blockquote>
<br>
</body>
</html>