Hi Brian,
This is an issue larger than DotNetNuke (which you will have noticed if you happened to catch the congressional hearings on PCI last month). 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).
Some additional meandering thoughts:
* PA-DSS auditing often requires a six-figure expenditure. You are likely to see NO free, open-source options CMS engaging in this process, especially when those platforms do not offer e-commerce as a core, primary feature. I do not believe that any are currently engaged in validation.
* There is a bit of a chicken-and-egg affair going on. DotNetNuke does not itself engage in any PCI-DSS or PA-DSS activities. There is no incentive for it to consider the validation process, except perhaps for the philanthropic benefit of commercial third parties (who themselves would make a lot of money off of this). Economically, this implies that the benefiting party (e.g., ASPDNF) should be the one to incur the high costs associated with PA-DSS validation.
* ASPDNSF must justify any non-PA-DSS software that it itself consumes, and in this case this means DotNetNuke. This complicates their validation strategy.
* Ironically, DotNetNuke can be fully PCI-DSS compliant and could be PA-DSS compliant (I recently dealt with the last issue of which I am aware, §11.1, dealing with multi-factor authentication). It is merely missing a custom security distribution and the validation process itself, for which it has little incentive.
* Out of the box, however, DotNetNuke is neither PCI-DSS nor PA-DSS complaint; its default security configuration is insufficient for this. Modification to its configuration may obviate PA-DSS and trigger Level-1 PCI-DSS compliance for your customer; DotNetNuke is HIGHLY compatible with this process.
* 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. The few details about the specific PA-DSS issues with which ASPDNSF is struggling serves to increase this suspicion. If it really wanted to, ASPDNSF could likely avoid DotNetNuke dependencies for PA-DSS-specific tasks.
Ultimately, the relationship between open-source and PCI is dynamic and antagonistic. There are many, many, many non-compliant sites out there that will require radical adjustment to reach compliance. No one knows what will happen here. I certainly do not.
Brandon