I suspect that ASPDNSF's equivocation about DotNetNuke PA-DSS is a red herring to distract from its own internal validation; here the VAST majority of compliance issues will relate to its own software, and very little will apply directly to DotNetNuke.
Your suspicions here are unfounded honestly, and statements misleading. Your tone indicates that AspDotNetStorefront inherently has numerous compliance issues on its own, which is 100% inaccurate. AspDotNetStorefront ML (on which the ML/DNN platform is largely based) has zero compliance issues as evidenced by our status as a PABP-certified payment application (short history lesson - PABP was replaced by PA-DSS when Visa transferred the project to the PCI security standards council - we are currently grandfathered into PA-DSS due to our certification against PABP v1.4). We as a company (and I personally as the compliance officer on two certifications now) are fully aware of the requirements to achieve certification, and factually, the majority of compliance issues will actually be found within the DNN framework.
The DNN framework functionality requires as much scrutiny as the ecommerce components, and perhaps more due to the fact that DNN handles many of the security, logging, error handling, form handling, data access, and administrative functions on the site. The areas where AspDotNetStorefront would be required to make changes corresponds nearly 100% with areas where our application relies on DotNetNuke to perform protected functions.
It is also important to note that PA-DSS compliance is NOT a list of checkboxes and a security scan. There are a great number of processes and procedures that are required to achieve full compliance, including following a strict SDLC, security breach research and response procedures, code review policies for developers, secure hiring practices, documentation requirements, and other quality system components that must be in place within DNN Corp before there is ANY chance of PA-DSS certification. This also calls into question any community-developed code that makes its way into the core platform. It is a complete company-wide commitment to secure application development practices, and requires regular evidence of following those practices to maintain your certification status. These are all things that AspDotNetStorefront has already undergone, and we are fully and 100% compliant with PA-DSS standards within both the AspDotNetStorefront ML and ML/DNN platforms based on the results of our last external audit as both products follow the same (compliant) SDLC.
The few details about the specific PA-DSS issues with which ASPDNSF is struggling serves to increase this suspicion.
We are aware of MANY of the areas in DotNetNuke that would require changes to meet PABP requirements. We aren't "struggling" with anything except getting DNN to cooperate. Without a commitment from the DNN team to address the issues it is a pointless waste of time. We have asked for that commitment for ~two years now (or somewhere thereabouts) and haven't received it. For example, doing a quick check of my currently active email folder, I found this, to Joe B, Shaun W, and Nik K. dated February 19th of 2008 (yes, that is over a year ago already).
Subject: please advise on PABP plans for DotNetNuke + ASPDNSF
[omitted]...cost to do cert is about $X and must be done jointly with DNN due to DNN owning many customer password and security mgmt areas.
That same check revealed that we received zero responses to that inquiry, just as we received zero responses (or at least nothing encouraging) to the half a dozen or more other emails and calls regarding the matter.
If it really wanted to, ASPDNSF could likely avoid DotNetNuke dependencies for PA-DSS-specific tasks.
This is actually 100% accurate. That specific (PABP Certified) product is already for sale on our website. It is called AspDotNetStorefront ML. Buy it, load it within an iFrame in your DNN site, and you are good to go. One of the biggest draws to the DNN platform however is the single sign-on capability and centralized administration. Guess what... both of those are going to fall under PA-DSS jurisdiction and both are handled by the DotNetNuke platform. If you did away with those, what you basically have is two separate websites.
Indeed, there exist (by my count) only THREE PA-DSS-compliant shopping cart applications on the PCI list (although, granted, such listing is sufficient but not necessary for PA-DSS compliance -- you do not have to be listed to be compliant).
This comment is also a bit misleading without a full explanation of the differences between PCI-DSS compliance and PA-DSS compliance. Though I won’t go into the intricacies, PCI-DSS compliance is primarily concerned with the implementation of the payment environment. Yes, this does include using secure applications, but also deals in great detail with things like network security, encryption, labeling, and handling of backup data, access control to servers/data centers, storage of paper records, logging of activities on servers that host payment applications, deployment of anti-virus and IPS/IDS systems, and so on. These are fully outside of the scope (and control) of the AspDotNetStorefront application (and DotNetNuke for that matter). In other words, PCI compliance is largely the responsibility of the merchant and hosting provider, not the application developer.
PA-DSS (again, formerly PABP) is primarily concerned with the application itself. For example, it requires coding practices that securely overwrite sensitive data, logs administrative actions within the software, handles invalid logins properly, handles errors without disclosing sensitive data, properly encrypts sensitive data when appropriate, and provides for overall secure development and release practices (as I mentioned briefly above).
The number of PA-DSS compliant applications on the PCI-DSS list is completely irrelevant as an indicator of application security. By nature, any commercial payment application in which the merchant has ANY control over the security environment is not going to be out-of-the-box PCI-DSS compliant because said merchant has requirements as well (for example, following best practices for password security). Any application that claims otherwise most likely has (or should have) some very fine print attached to that claim.