FPT_API_EXT.1.2 points to a URL as a(n objective) requirement.

[kgal]

Referencing a URL is not advisable b/c it's too mutable.

[WeeknightMVP]

A URL (Uniform Resource Locator) is immutable; that's its very point http://tools.ietf.org/html/rfc3305. The associated resource, the IANA Media Types Registry, is what's mutable, and that's its very point http://tools.ietf.org/html/rfc2046. This registry is well-known, established, and referenced by numerous ubiquitous standards for the friggin' Internet that refer to it by its RFC (which in turn references this URL) and that make Common Criteria look amateurish.

What is the problem? Maladaptivity. Common Criteria has established a precedent of not adapting, for the sake of equity. What's more important: playing fair to accommodate competitors that are late to the game, or expecting products (not to mention processes) to keep up with changing times? Common Criteria processes in their present form are not engineered to keep pace with an adaptive marketplace, and that needs to change, or the marketplace will bury Common Criteria in its collective wake.

On Tue, Jun 24, 2014 at 12:10 PM, kgal notifications@github.com wrote:

Referencing a URL is not advisable b/c it's too mutable.

— Reply to this email directly or view it on GitHub https://github.com/commoncriteria/application/issues/33.

Matt Benke

[kgal]

Referencing a web page whose content is controlled by a private corporation is a radical departure from traditional CC requirements. I'm not saying it's not warranted; but there are some questions that we should think through, like: What happens if the web page changes in a meaningful way during evaluation? Is IANA neutral enough (how do we measure its neutralness)? etc...

[WeeknightMVP]

What happens if the web page changes in a meaningful way during evaluation?

Then it doesn't apply to the current evaluation; it applies to future updates to the product, ST, and VR (as reported in MRs); see below for acronyms.

Is IANA neutral enough?

IANA http://www.iana.org/about, a corporate entity originally founded by the US Government, controls the media types registry (among other responsibilities) under contract http://tools.ietf.org/html/rfc2860 with the US Department of Commerce http://www.commerce.gov/about-department-commerce in coordination with the IETF http://www.ietf.org/about/, an open international consortium. This arrangement is trusted by the W3C and other similarly prominent standards bodies. The contract is subject to annual renewals and occasionally opened for competitive bidding. This checks and balances concerns about IANA (or any future hosts) making self-serving changes to the registry. But your point makes sense in the general case...

-----TL;DR-----

(Blabbering about a pie-in-the-sky collaborative future. Suggest skipping ahead to obstruse suggestion for rephrasing FPT_API_EXT.1.2.)

We are not just writing a few Protection Profiles -- we are trying to streamline outmoded procurement processes, including those incorporating the Common Criteria in its current sluggishness. The ontology of Common Criteria is not to blame -- it's the bureaucracy.

Think of _C_ommon _C_riteria (and _P_rotection _P_rofiles, _S_ecurity _T_argets, _V_alidation _R_eports, _M_aintenance _R_eports, etc.) not just as isolated atomic documents, but as a network of dependencies among individual parts of these documents (objectives, requirements, AAs, etc.) and external references (e.g. the IANA Media Types Registry), maintained not just by a cadre of meddlesome bureaucrats, but by communities of stakeholders from industry, government, and academia representing various conflicting but resolvable interests. So a hypothetical ST for, say, Adobe® Reader®, could go up against the Apps PP, but we (or other experts) might update certain parts of our Apps PP in the future (under our oversight, while we or our delegates retain final editorial control of branched versions), and Adobe® might update Reader® in ways relevant to certain parts of our PP and/or their ST (e.g. from [version] XI to XII). Then the old ST for Adobe® Reader® is not necessarily irrelevant w.r.t. the updated Apps PP, it is just "stale" -- by examining the parts of the PP that changed modulo the dependencies of the old Adobe® Reader® ST, and the changes between versions of the ST, we have some hope to isolate the changes necessary to revalidate the ST for the updated Adobe® Reader® against the updated Apps PP without restarting everything from scratch while contrained by the schedules of overworked feds and CC lawyers. At least that's how I think the process should work. Common Criteria has a (very sluggishly implemented) process for "maintaining" such PPs and STs, documented as MRs that include impact analyses along these lines. The problem is in part the current process (which requires iterative consensus of a bureaucracy and stakeholders with conflicting interests during brief windows of splenetic teleconferencing followed by dawdling comment cycles, rather than accommodating 24/7 collaboration, calling upon delegates to resolve disputes, and periodically branching off release versions as the underlying trunk continues to be collaboratively updated), and in part the crude tools with which this outdated process is currently implemented (PDFs and other proprietary formatted documents, instead of hyperlinked collaborative XML/XHTML that can be arbitrarily formatted, even into PDFs), not to mention that such changes are rarely so...clean-cut. That's just an example of internal dependencies over which we retain some clout. However, to promote ubiquity in our PPs such that industry can realistically produce off-the-shelf IT products that our government customers can realistically evaluate, procure and use, we must leverage the ubiquitous standards and practices upon which such products are based: standards like HTML, TLS, IANA Media Types, FIPS, etc., that continually change, mostly outside our purview.

Some key concepts that will enable us to streamline the current process are role-based collaboration, versioning, and dependency tracking. Individual parts of CC-related documents might depend on ubiquitous standards (ideally ones that can be apportioned to isolate changes similarly to the above); these can be continuously monitored to account for the state of a given dependency at a given time (e.g. time of ST validation or maintenance), accommodate initial development of products (and corresponding STs) by vendors that are validated against our PPs (whose trunks are collaboratively discussed and edited by any registered experts, but whose branches are finalized under our direct jurisdiction), and call for products to periodically update in sync with such dependencies (and for evaluators to periodically maintain that validation and produce VRs). In the above example, Adobe®'s hypothetical ST would claim that Reader® XI meets FPT_API_EXT.1.2 (because parsing files of IANA media type 'application/pdf' for reading is a primary feature of Reader®), and our ITSEF's VR would trivially validate it. Now suppose some consortium (with protuberant Adobe® representation) comes along and registers some new but relevant media type, e.g. 'application/pdf+xml', and Adobe® adds a feature to Reader® to import/export it. We would like to account for the change not just for STs against future versions of the product (e.g. Reader® XII), but in the maintenance of the current ST validation (e.g. Reader® XI.2.3); but how do we state that objectively? Here's a first crack at it:

PP.APP(1) [IANA MTR] IANA Media Types Registry, http://www.iana.org/assignments/media-types/media-types.xhtml [RFC 2860] RFC 2860: Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, http://tools.ietf.org/html/rfc2860 (Refers to [IANA MTR].)

ASSN.FEATURED_MEDIA_TYPES [Assignable: list of media types advertised by the application (TOE) as a parser thereof]

ASSN.MEDIA_TYPE_REGISTRY [Assignable: the most recent RFC subsuming [RFC 2860], inclusive, at the time of validation] Depends: [RFC 2860]

ASSN.REGISTERED_MEDIA_TYPES [Assignable: list of all media types processed by the application (TOE) in common with the media types listed in ASSN.MEDIA_TYPE_REGISTRY, at the time of validation*] Application Note: As of [time of publication of this PP], the applicable media type registry was the [IANA MTR].

• FPT_API_EXT.1.2*
• For each structured file whose format is listed in ASSN.REGISTERED_MEDIA_TYPES, the application (TOE) must either document parsing it as a feature (as listed in ASSN.FEATURED_MEDIA_TYPES), or invoke a parser provided by its platform (OE). AA.MEDIA_TYPE_LIST The evaluator shall test that the application (TOE) processes all media types listed in ASSN.REGISTERED_MEDIA_TYPES, and no others registered in the ASSN.MEDIA_TYPE_REGISTRY. *
• AA.MEDIA_TYPE_DELEGATION The evaluator shall test that for each media type listed in ASSN.REGISTERED_MEDIA_TYPES, the media type is listed in ASSN.FEATURED_MEDIA_TYPES or is parsed by the platform (OE).* Conforms: CC(3.1r4)

(STs, VRs, blah blah blah, not our department for now. Suggest stopping here.)

ST.ADOBE_READER(XI) ASSN.FEATURED_MEDIA_TYPES [Assignment: 'application/pdf'] Assigns: PP.APP(1)/ASSN.FEATURED_MEDIA_TYPES

ASSN.MEDIA_TYPE_REGISTRY [Assignment: [IANA MTR]] Assigns: PP.APP(1)/ASSN.MEDIA_TYPE_REGISTRY

ASSN.REGISTERED_MEDIA_TYPES [Assignment: 'application/pdf'] Assigns: PP.APP(1)/ASSN.REGISTERED_MEDIA_TYPES

FPT_API_EXT.1.2 For each structured file whose format is listed in ASSN.REGISTERED_MEDIA_TYPES, the application must either document parsing it as a feature (as listed in ASSN.FEATURED_MEDIA_TYPES), or invoke a parser provided by its platform. Derives: PP.APP(1)/FPT_API_EXT.1.2

Conforms: PP.APP(1)

VR.ADOBE_READER(XI) FPT_API_EXT.1.2 True Validates: ST.ADOBE_READER(XI)/FPT_API_EXT.1.2

AA.MEDIA_TYPE_LIST
  True
  Rationale: The little drop-down Open dialog box thingie only lists

"Adobe PDF Files (.pdf)" and "All Files (.*)" as options; our magic file utility accused all the Adobe® Acrobat® output PDFs we tested of being media type "application/pdf". (Note: Acrobat® is Reader®'s sister application that writes PDFs; it has not yet been submitted for validation.) Validates: ST.ADOBE_READER(XI)/FPT_API_EXT.1.2/AA.MEDIA_TYPE_LIST

AA.MEDIA_TYPE_DELEGATION
  True
  Rationale: Adobe® Reader® XI (the TOE) advertises PDF parsing and

manipulation right on the box. A brief search on the Internets revealed PDF to indicate files of media type 'application/pdf', the only type listed in ST.ADOBE_READER(XI)/ASSN.FEATURED_MEDIA_TYPES. Validates: ST.ADOBE_READER(XI)/FPT_API_EXT.1.2/AA.MEDIA_TYPE_DELEGATION

Validates: ST.ADOBE_READER(XI)

Event: 'application/pdf+xml' registered to [IANA MTR] --> ST.ADOBE_READER/ASSN.MEDIA_TYPE_REGISTRY (refers to [IANA MTR], this is unaffected, dependencies could be) --> ST.ADOBE_READER/ASSN.REGISTERED_MEDIA_TYPES (Adobe® Reader® XI does not process (hypothetical) 'application/pdf+xml', so this and dependencies are unaffected.)

Event: Adobe® Reader® XI updated to XI.1.1 to parse 'application/pdf+xml'. ST.ADOBE_READER/ASSN.FEATURED_MEDIA_TYPES updated to ('application/pdf', 'application/pdf+xml'); ST.ADOBE_READER/ASSN.REGISTERED_MEDIA_TYPES updated to ('application/pdf', 'application/pdf+xml') (Dependencies (FPT_API_EXT.1.2) could be affected.) --...--> VR.ADOBE_READER/FPT_API_EXT.1.2 must be revalidated; updated to: True Validates: ST.ADOBE_READER/FPT_API_EXT.1.2

  AA.MEDIA_TYPE_LIST
    True
    Rationale: The little drop-down Open dialog box thingie only lists

"Adobe PDF Files (.pdf)", "Adobe PDF XML Files (.xml)", and "All Files (.)" as options; our magic file utility accused all the Adobe® Acrobat® output PDFs we tested of being media type "application/pdf" and all output PDF XMLs we tested of being media type "application/pdf+xml"*. (Note: Acrobat® is Reader®'s sister application that writes PDFs; it has not yet been submitted for validation.) Validates: ST.ADOBE_READER/FPT_API_EXT.1.2/AA.MEDIA_TYPE_LIST

  AA.MEDIA_TYPE_DELEGATION
    True
    Rationale: Adobe® Reader® XI (the TOE) advertises PDF parsing and

manipulation right on the box and bragged about their PDF/XML* parsing in their XI.1.1 update documentation. A brief search on the Internets revealed PDF to indicate files of media type 'application/pdf' and PDF XML to indicate files of media type "application/pdf+xml"*, the only types listed in ST.ADOBE_READER(XI)/ASSN.FEATURED_MEDIA_TYPES. Validates: ST.ADOBE_READER/FPT_API_EXT.1.2/AA.MEDIA_TYPE_DELEGATION Intermediate dependencies are marked resolved.

Events: Adobe® Reader® XI goes through subsequent updates for various unrelated reasons. ST.ADOBE_READER comes up for periodic maintenance when the TOE (Adobe® Reader® XI) is at version XI.2.3. Authorities branch off ST.ADOBE_READER(XI.2.3) and VR.ADOBE_READER(XI.2.3), check wording, check dependencies of updated nodes for resolution, and declare them maintained; MR.ADOBE_READER(XI.2.3) comprises rationale.

• "Time of validation" in the above assignments means when an ST is initially submitted, a versioned ST when it is up for maintenance, or the live ST if authorized validation is performed between maintenance cycles.

-----TL;DR-----

Okay, so this is a naive idealistic perspective, I am sweeping a lot under the rug, it's not a one-man operation, etc. But if you think this is nuts, stop for a moment to consider what we do now.

[kgal]

Would it be appropriate to list a time window in the requirement, like "If there is a change in the IANA formats in the period of 90 days before evaluation until its completion, the application may comply with either IANA definition" to explicitly define a buffer period?

[jeffblank]

Ugh. As much as we like this, perhaps we should simply shelve the requirement, in favor of something that would involve enumerating 3rd-party code or libraries that are included? Let's discuss / please reply.

[bourdett]

At a minimum we at least want to get the list of the all the 3rd party packages / parser's used in an application.