### General comments The overall document has several critical issues and cannot be submitted this way. Purpose of the document is to state a work plan, hence it is very important to stick to real timeliness. A work plan reviewed on month 6 cannot mention it is a status report at month 3 in its main page. For the sake of correctness and coherence, no backward date should be stated. Main structure with harmonization and evolution is fine, but there is a problem: it's not clear if sections are about Product Teams or Objectives. Some information is missing (Cesnet security product team work plan) and some is wrong, please read detailed comments for suggestions. From an SA1 point of view, that is, keeping in mind the 4 objectives listed in https://twiki.cern.ch/twiki/bin/view/EMI/SA1 and its respective work description, the document should at least give links or resources to show what a system administrator or security administrator has to do when deploying and maintaining each of the existing middleware platforms in order to perform security harmonization and evolution. Observations will be in the Detailed Comments, especially for Argus integration. JW: For a JRA1 work plan it is not correct (or highly speculative) to give deployment and maintenance links/resources. The release anyway deals with these issues in the certification and integration processes. Therefore I will not add this additional material to this document as a fair proportion does not exist.. (Common AuthN libs?) ### Additional recommendations (not affecting the document content, e.g. recommendation for future work) On Work Plan documents, always keep the time information correct. Any back-in-time deadline should be avoided. JW: OK. Will correct dates... were accurate at the time of submission to the PTB/PEB for review. After that, it took a VERY long time to find reviewers or even figure out what should be done next. Cross check whenever possible and keep the informations up to date on each document release. Incorrect statement can easy bring very bad security issues. From the SA1 point of view, security report should address the operations impact in production scenarios so to estimate the effort needed on different site to move towards security harmonization and evolution. In particular for each platform should highlight: - Changes in deployment scenarios that will lead to repackaging of software packages, i.e. if a new component has to be added on sites to perform security tasks - Changes in maintenance scenarios that will lead system administrators to acquire new knowledge, i.e. maintenance task of "alien" components or EMI components not present in original middleware packages/deployment scenarios JW: This is not in the scope of a JRA1 document... and are better produced in a SA1 document from the (same) PTs. ### Detailed comments on the content N° Page Section 1 1 Abstract Observations Change "The status report at M03" with "The first release of this document" Is Addressed? NO JW : Will change... although the original abstract instructions were to include the text verbatim from the DoW. N° Page Section 2 8 3. State of the art, paragraph 6 Observations Change "proxy-renewal service" to "proxy-renewal tool" "proxy renewal service" mentioned in line 3 is not a service, as it doesn't fulfill requests or cannot be queried. It is a tool or utility; use any other word that clearly shows it's just an automated task not waiting for requests. Is Addressed? NO JW: Yes... OK. This is more correct. N° Page Section 3 9 3. State of the Art, paragraph 5 from the beginning of the page Observations Remove he whole paragraph "There is a remote policy decision ... for securing communications" Charon is not an EMI component. Is Addressed? NO JW: OK. N° Page Section 4 11 4.1 Observations Clearly state that Harmonization work plan is shown as Product Teams AND as Objectives. The following observations will appoint each of those. Is Addressed? NO JW: OK. N° Page Section 5 11 4.1.1. Observations Change section name from "ARC Security Utils" to "ARC Security Utils Product Team" Is Addressed? NO JW: OK. N° Page Section 6 11 4.1.2. Observations Change section name from "ARGUS" to "ARGUS Product Team" Is Addressed? NO JW: OK. Correctly it is called Argus not ARGUS (it's not an abbreviation) N° Page Section 7 11 4.1.2. Observations Content of this section are outside the context of harmonization. Al the content of this chapter should be moved to section 4.2.2. unless is possible to show harmonization value in the Product Team tasks. Instead of listing ARGUS complete work plan, selected harmonization-oriented ARGUS PT task should be listed aiming to answer these questions: - Which are the benefits of integration with respect to each middleware platform - By which means integration is leading to harmonization and at what cost for each middleware platform (what leverages to previous security asset?) JW: The overall benefits are outlined in the DoW. If all these things are just unaddressed or unclear, they should be left as open questions / tasks to plan in the document. See Detailed comments 8,9 for my proposal about contents of this section. Is Addressed? NO N° Page Section 8 11 4.2.1. Observations To be consistent with the Argus harmonization purposes, the follwing should be added: ARGUS PT should fetch information needed from ARC and UNICORE developers to build ARC and UNICORE XACML Profiles, with the aim of creating a unified XACML profile, in order to integrate ARGUS in the two middlewares. Is Addressed? NO JW: Will add. JW: On further reflection I have modified a sentence in the "Compute Area AuthZ" section to read: "Gather the XACML profile requirements of the different Compute Elements of the middleware." There are a few reasons for this way: 1. It's not actually just the Argus PT that is gathering this info, there are "external" people to Argus PT participating in this XACML group. 2. I am trying to avoid saying things like "ARC and UNICORE developers" or "glite developers" since EU wants us to be EMI. Not three stacks. 3. Can't remember... N° Page Section 9 11 4.2.1. Observations From a SA1 point of view: Should be specified how deployment scenarios and maintenance will change for each middleware, i.e. if the PEPD client has to be installed on nodes or on servers, on gLite CE or on ARC CE, on a separate server, on which kind of server and how different they are the two different stages: - until there are no XACML profiles (that is, by using the PEPD as intermediary) - when we will have an XACML profile for each middleware but we still not have an XACML common profile. Work plan should also suggest how the integration will be supported and monitored, if it's the ARGUS PT doing the support, and if not, suggest someone. Is Addressed? NO JW: Like above, will not include integration/deployment information in a JRA1 document. N° Page Section 10 12 4.1.3. VOMS Observations Change section name from "VOMS" to "VOMS Product Team" Is Addressed? NO JW: OK. N° Page Section 11 12 4.1.3. VOMS Observations At the end of paragraph 1, change "is now deployed in gLite and ARC" with "can now work together with gLite and ARC" Is Addressed? NO JW: Well the VOMS-SAML version (amything greater than 1.8 I believe) is deployed in gLite and ARC. The fact that the SAML part is not used yet is another issue. N° Page Section 12 13 4.1.4. gLite Security Observations Change section name from "gLite Security" to "gLite Security Product Team" Is Addressed? NO JW: OK. N° Page Section 13 14 4.1.5. UNICORE Security Observations Change section name from "UNICORE Security" to "UNICORE Security Product Team" Is Addressed? NO JW: OK. N° Page Section 14 14 4.1.5. UNICORE Security Observations Paragraph 2, Remove the entire line "This deliverable should be completed by project month 3" Paragraph 3, Change the word "deliverable" with "task" as deliverable can be misinterpreted as an EMI deliverable. Actually the word deliverable here is referred to an UNICORE deliverable and not to an EMI one. Paragraph 4, Remove the sentences "by EMI project month 4" and "by EMI project month 6. Paragraph 4, Change the word "deliverable" with "task". Paragraph 6, Change the sentence "A deliverable to this group's activities ... month 3" to "A detailed list of features from the UNICORE side will be released". Remove "for EMI project month 7". Is Addressed? NO JW: Will remove outdated references and add more generic terms. I will change "deliverable" to "UNICORE deliverable" as the call-out is a tangible result of some work. We have overloaded the usage of th word deliverable whereas most should be described as a "deliverable document". I will change the last one to "list of features" though. N° Page Section 15 14 Missing section Observations Insert a section "4.1.6. CesNet Security Product Team" Even if this is planned to be closed, clearly point it into the document. Is Addressed? NO JW: Will add the section, I will have to re-ask if there are any developments planned. Given the nature of the S/W there should not be any! N° Page Section 16 14 4.1.6. GSI Removal Observations Change section number and name from "4.1.6. GSI Removal" to "4.1.7. GSI Removal Objective" Is Addressed? NO JW: As above... this is not an objective but an ongoing task. N° Page Section 17 14 4.1.6. GSI Removal Observations Change the sentence "An overall .... is outlined in the DoW and Technical Development plan" to "Removal of Globus Security Infrastructure (GSI) protocol, which functions as an "enhanced" SSL protocol, is proposed in this plan. The statement contained in the document is false because none of these documents contain this proposal. This is the work plan document intended to propose, plan and evaluate these changes as is clearly explained in the rest of the section. Is Addressed? NO JW: Addressed in EMI Part B document (JRA1.3). As for the technical development plan... this is not even finished yet. will remove reference to it. N° Page Section 18 15 4.1.6. GSI Removal Observations Remove the sentence "This plans should be concluded before EMI project month 4" Is Addressed? NO JW: Will do. I will replace by EMI project month 6. JW: Actually month 7 (November!) N° Page Section 19 15 4.1.7. Common Authentication Libraries Observations Change section number and name from "4.1.7. Common Authentication Libraries" to "4.1.8. Common Authentication Libraries Objective" Is Addressed? NO JW: No. Then we will get mixed up with technical objectives in DNA1.3.1. I will add "Task" as this and other similar are tasks that need to be done to fullfil an overall objective. N° Page Section 20 15 4.1.7. Common Authentication Libraries Observations Remove sentence "These points ... month 4" Is Addressed? NO JW: Like above ... month 6. N° Page Section 20 15 4.1.8. Common SAML profile Observations Change section number and name from "4.1.8. Common SAML profile" to "4.1.9. Common SAML profile Objective" Is Addressed? NO JW: See above (19) N° Page Section 21 16 4.1.9. Compute area authorization Observations Change section number and name from "4.1.9. Compute area authorization" to "4.1.10. Compute area authorization Objective" Is Addressed? NO JW: See above (19) N° Page Section 22 16 4.1.9. Compute area authorization Observations Change sentences "The requirements ... will be produced" to "After the requirements gathering, an internal milestone document answering the above points will be produced" Is Addressed? NO JW: OK. N° Page Section 23 16 4.1.9. Compute area authorization Observations As gLite, UNICORE and ARC maintain user mappings in different places, the Compute Area Authorization Objective should also clearly state whether a standardized user mapping over the 3 stacks will be adopted, or each stack will still be able to maintain its own way of mapping local users to grid users. It is not clear which model is to be chosen as ARGUS, gLite and UNICORE seem to be keeping user mappings into separate security objects while ARC is maintaining this information on each ARC CE. Further discussion on this subject has to be taken into account as it heavily affects how authorization and authentication data is moved from the computing site to the authorization/authentication infrastructure. Is Addressed? NO JW: This is exactly why there is a group following this task. Usage of Argus does not dictate any one mapping method. The ARC rep(s) to the Argus group take care of this subject. N° Page Section 24 17 4.2. Observations Clearly state that the work plan is defined for Product Teams. Is Addressed? NO JW: OK. N° Page Section 25 17 4.2.1. Arc Security Utils Observations Rename section "4.2.1. Arc Security Utils" to "4.2.1. Arc Security Utils Product Team" Is Addressed? NO JW: OK. N° Page Section 26 17 4.2.2. Argus Observations Rename section "4.2.2. Argus" to "4.2.2. Argus Product Team" Is Addressed? NO JW: OK. N° Page Section 27 17 4.2.3. VOMS Observations Rename section "4.2.3. VOMS" to "4.2.3. VOMS Product Team" Is Addressed? NO JW: OK. N° Page Section 28 17 4.2.4. gLite Security Observations Rename section "4.2.4. gLite Security" to "4.2.4. gLite Security Product Team" Is Addressed? NO JW: OK. N° Page Section 29 17 4.2.4. gLite Security Observations Change every occurrence of "Computing Elements", "(CE)" to "gLite Computing Elements" or "gLite CE". There has been a slight misunderstanding of these names and it is often the case that it's possible to thing that every CE (also ARC and UNICORE ones) runs gLite, which is false. Is Addressed? NO JW: OK. N° Page Section 4 17 4.4.2 Observations Is Addressed? NO JW: Something missed here? N° Page Section 3 16 4.1.9 An open question remains that should be addressed in the context of authorization regarding user mappings, deployment and maintenance of CE. It is not clear which model is to be chosen as ARGUS, gLite and UNICORE seem to be keeping user mappings into separate security objects (ARGUS/gLite in the PEPD, UNICORE in X.509 certificates) while ARC is maintaining this information on each CE. Further discussion on this subject has to be taken into account as it heavily affects how authorization and authentication data is moved from the computing site to the authorization/authentication infrastructure. Is Addressed? NO JW: Same as above comment (23) Typos and missing acronyms: Mostly all of the acronyms are missing. JW: Will check. But I'm pretty sure all abbrevs are defined in text at first usage if needed (that's the beauy of using LaTeX...)