Task Force (TF) meeting of 2005-01-18

Participants:
Maria Dimou (from home), Joni Hahkala, Dave Kelsey (on the telephone), Tanya Levshina (on the telephone), Karoly Lorentey, Ian Neilson, Valerio Venturi (on the telephone), John Weigand (on the telephone).

Agenda: Agreed in advance via email:

1. Comments on the previous meeting's notes
http://cern.ch/dimou/lcg/registrar/TF/meetings/2004-11-29 - All
                                                                                
2. Comments on Tanya+John's paper on how VOMRS will manage the
certificate of various CAs, their expiration, addition  or deletion etc
http://www.uscms.org/SoftwareComputing/Grid/VO/design/ca.htm (or .doc) - All

3. Comments on the pre-alpha VOMRS https://hotdog62.fnal.gov:8443/vo-LCG/vomrs
containing hooks for ORGDB attachment in the future. Registration requires
personal certificate loaded.  - All
                                                                                
4. ORGDB link progress - Karoly
                                                                                
5. Discussion on last meeting's A.O.B. i.e. review the plan for ORGDB
information linking and LHC VOs' transition to VOMS/VOMRS. - All
                                                                                
6. Action list review - All

7. A.O.B.
                                                                                
8. Select date for next meeting (how about 22/2 @ 16hrs?)

1. Comments on the previous meeting's notes:

The notes were accepted.

2. Comments on the VOMRS CA/Member Certificate Management paper:

The paper proposes an automatic synchronization between the CA certificates stored on the machine where VOMRS is installed ($TRUSTED_CA directory) and the list of CAs accepted by each VO configured on that host. In case of CA root certificate expiration this list of CAs accepted by a VO will be automatically updated. The proposal was considered useful because:

The issue came up at the meeting on whether we can have certificates with the same DN issued by 2 different CAs. Ian explained that this may happen in cases when the root certificate of a given CA expires and gets renewed by another CA with a different key and signature.

A lot of feedback was received in email that should be incorporated in the paper (actions and appendix).

3. Pre-alpha VOMRS test

We should all register in https://hotdog62.fnal.gov:8443/vo-LCG/vomrs and become VO Admins, if we want. Tanya suggested that the complete text of an "Executive Summary" of the Usage Rules or Acceptance Use Policy (AUP) be published on the VOMRS Registration page, so that we can hope that the users will actually read what they agree to. This was considered a very good idea. By the time these notes are written, it was discussed at the Joint Security Policy Group(JSPG) meeting of Jan. 24-25 and a general decision was taken that the AUP will no more be global across VOs, as it is today (what is linked from lcg-registrar, VOMS-admin, VOMRS), but every VO will have to devise its own AUP and link it from its user registration prompt.

4. ORGDB link progress

Karoly should provide the internal interface to the VOMRS developers. By the time these notes are written, Karoly got the database schema from a Foundation view for authorised users. Then, the VOMRS developers should have the necessary passwords to actually access the ORGDB in order to test the new hooks in their software. Karoly is investigating this with the ORGDB DBAs and Oracle Support. Tanya reported that FNAL was interested in the ORGDB link idea in general because they are looking into linking to the FNAL ORGDB for other applications.

5. VOMS/VOMRS plan review

A lot of things are done since the original plan was drafted. These things mainly concern:

However, there is a long way to go for:

It is a great concern of the TF that the new tools won't be in operational shape before Karoly leaves us in April 2005 and support issues will be complicated. See Grid Deployment Board (GDB) presentation of Feb. 8th and (*** ACTION 2004-09-17--13 ***) below.

6. Action list review:

(*** ACTION 2004-09-17--1***) On Ian's suggestion Maria will create 3 savannah tickets containing all the existing VOMS/VOMRS-related tickets across groups per category (Major, Normal, Enhancements). PARTIALLY DONE: The VOMS/VOMRS savannah summary page is now cleaner but present savannah search doesn't allow to select the 'severity' attribute value (even for display) across groups (lcgoperation OR jra1 OR jra3). Maria investigating with the savannah expert.

Ticket 860: Maria closed this ticket with Karoly's anwer. She opened ticket 1185 to describe the task of defining what to store on user's CA information. Please read the tickets for details. (*** ACTION 2004-09-17--2***) Tanya: VOMRS should also store the user certificate serial number and his/her CA's contact URL. PENDING

Ticket 1132: (*** ACTION 2004-09-17--3 ***) Tanya will make the necessary changes so that newly registered VOMRS users don't receive 2 almost identical emails when they pass from status "New" to "Approved" in the VO. By this date, Maria completed her action on making sure VOMRS notification emails will never fall into spam again. She informed the TF by email on the reasons and the solution (whitelisted the string "VOMRS" at the CERN central email gateway level). PENDING

(*** ACTION 2004-09-17--4 ***) Tanya should re-open the savannah ticket 1141 if a more user friendly error message can be envisaged by the VOMRS developers in case of expired user certificate. PENDING

(*** ACTION 2004-09-17--5 ***) Maria should make a CERN afs account for Tanya and do the necessary for her to obtain CVS write access. DONE for Tanya and John. Remove after next meeting.

(*** ACTION 2004-09-17--6***) Tanya will enter in the savannah group lcgoperation the bugs she has observed. Example: Simultaneous "commit" of changes via the User Interface and the VOMS db API causes the db tables to go out of sync. This is, most probably not a database problem but an application problem of voms-admin. PENDING

(*** ACTION 2004-09-17--7 ***) Recommend to CERN IT Management on information quality improvement for CERN HR db. (*** ACTION ***) Maria. (Maria feels this can only be done when the ORGDB content quality is fully understood but Ian in the 2205-01-18 meeting recommended that we move ahead with this action already now). PENDING

(*** ACTION 2004-09-17--8 ***) The ORGDB view with the necessary and sufficient Personal User data, according to the Requirements' definitions may need to be tailored according to experiments' rules Karoly and Maria to investigate and inform the TF. PENDING

(*** ACTION 2004-09-17--9 ***)Maria will test VOMRS and make available to the TF a list of features. By the time these notes are written, Tanya announced mid-December 2004 the pre-alpha version https://hotdog62.fnal.gov:8443/vo-LCG/vomrs for testing. PENDING

(*** ACTION 2004-09-17--10 ***) Tanya expressed worries that US-CMS users won't accept to type their birthdate, even if it is only DDMM (no year) and even if it is not logged in clear, simply a string saying that it was provided. She also said they might be reluctant to register in CERN HR db, even if this is LHC experiment policy. She should give the TF feedback from discussions on this matter with her community. PENDING

(*** ACTION 2004-09-17--11 ***) Maria create savannah ticket for VOMS admin and VOMRS to set Return-email-address to the one of the VO manager for user notifications that can't reach the recipients. PENDING

(*** ACTION 2004-09-17--12 ***) TF to re-discuss the Usage Rules re-acceptance prompt in more detail. PENDING

(*** ACTION 2004-09-17--13 ***) LCG deployment management has to plan for VOMS admin software maintenance continuity after Karoly's departure from CERN in April 2005. LCG/EGEE management has to plan for EDG trust manager support continuity after Joni Hahkala's departure from CERN. PENDING

(*** ACTION 2004-09-17--14 ***) Ian should investigate with the LCG Deployment management whether resources could be found elsewhere in the community to assist Tanya in the VOMRS development work. CLOSE after John's assignment to VOMRS development?

(*** ACTION 2004-10-28--1***) Tanya to make a UML diagram in addition to the VOMRS Registration Process flow and to the VOMRS_new_req document they prepared with John.

(*** ACTION 2004-11-29--1***) Karoly to make available a sceleton of Classes for VOMRS developers to use when interfacing to the ORGDB.

(*** ACTION 2004-11-29--2***) John and Tanya to submit in savannah (project=lcgoperation) the problems they mentioned at the meeting related to voms-core code when using "voms-proxy-init" and anything else they want to report to the developers. Savannah is the communication medium that helps the TF check where we stand in the process. All, please close tickets when actions done.

(*** ACTION 2005-01-18--1***) John and Tanya to update their CA management paper.

7. A.O.B.

 

8. Next checkpoint meeting:

The next meeting will be held on 22 Febuary 2005 at 16hrs in room 28-R-006.

Appendix: The VOMRS CA Management email thread

From tlevshin@fnal.gov Mon Feb 14 16:40:17 2005
Date: Wed, 19 Jan 2005 11:29:07 -0600 (CST)
From: Tanya Levshina 
To: Karoly Lorentey ,
    Joni Hahkala , Maria Dimou ,
    David Kelsey , Ian Neilson ,
    vo-project@fnal.gov
Subject: Re: VOMRS Certificate Authority/Member Certificate Management
    (second draft)

Hi,



Thank you very much for all your comments. I am really glad that
our document generated so many of them. I would rather  work on fixes now than
discover that all our work completely irrelevant later.

I've tried to organize comments and my answers so it will be easier to read. I 
am not sure that I achieved this goal though.

John proposed that we added this discussion to the document and I will do it 
for
a final version.
 
================================================================
Joni:
I must confess that I don't know when/who/why this document was  requested, so 
my points might be moot.

Tanya:
Nobody requested this document. This is a short explanation why we have 
started to work on it.
In VOMRS (and in VOMS) member is identified by unique tuple (DN, CA) that is
extracted from the  member's certificate.
VOMRS and VOMS store the list of CA certificate subjects. I guess it was done  
partially to simplify the life of the VO
administrators so they can select CA from the list while registering a new 
member. Probably, this is an absolutely unnecessary feature. But in any case  
we should worry about synchronization with the certificates that are stored in 
TRUSTED_DIRECTORY because we would like to keep in VOMRS and VOMS the correct 
status of the member certificate.
If VO completely relied on content of TRUSTED_DIRECTORY and did nothing 
regarding members' certificate then the following situation could arise:
	1. ca certificate disappears from TRUSTED_DIRECTORY
	2. VOMRS ignores it:
		 a. member can not login to VOMRS
		 b. member's certificate  status didn't change
		 c. member's certificate is still in VOMS and voms-proxy-init will produce a 
valid proxy

	3. a local grid cluster trusts this particular VO, so all  members are 
allowed to
	access this cluster.
        4. if cluster's administrator didn't remove the CA certificate from 
	the local TRUSTED DIRECTORY, the vo member with the certificate associated 
with the
	"deleted" CA can still use local resources
	
There is no mechanism (at least I have not heard about it) that allows local 
resource provider to keep TRUSTED_DIRECTORY in sync with VO list of trusted 
CAs. I hope that we propose a reasonable way to do so or, at least, provide the
capability of managing the set of CA certificates.

==================================================
Are you still with me? 
Let's continue ...
====================================================
Karoly:
,---
| Still, the record of the CA certificate and members' certificates
| associated with this CA will exist in a VOMRS database. Deletion of
| the members' certificates is not an option because this action is
| irreversible and if the removal of a particular CA certificate was
| inadvertent (an "oops"), recovery is impossible.
`---

I am probably misled by the wording of this paragraph, but does VOMRS
store the user's actual certificate, or only its identifying data (DN)?


Tanya:
We are storing tuple (DN - subject and CA - issuer) of the user certificate - 
same as VOMS
====================================================

====================================================


Joni:

 This document does handle one very important issue, which is the CA 
 certificate management, but I would rather aim for general solution for 
all services. Could this be extended and brought up at JSPG?

Tanya:

Unfortunately I do not even know what JSPG is ;).
But general strategy for services will be nice. The question is should we wait 
for it, or should we try to come up
with some acceptable solution and be ready to replace it when  JSPG or some 
other acronym comes up with a better one.  

So I think 
	a. we should understand if a solution exists and if it is suitable for VO
	b. if it doesn't , figure out if  anybody is concerned about this issue
	c. be able to handle it at the VO level until a better solution is found

Joni:
A general comments:
In EGEE the CA certificates, paths etc seem to be handled by the 
integration team, so this document should be discussed with them.
I fail to see why the CA certificate management for VOMRS would differ 
from CA cert management for any other service. All the issues mentioned 
 here will pop up will all services if the CA management would be handled 
properly in services.

Ian:
This is true, but where is it in the EGEE/JRA3 roadmap? I don't see it
in the recent Site Access Control Arch. Doc as a PDP and associated
management interface? Is this a missed or an unfulfilled requirement? 


Joni:

 It seems that there should rather be a general CA certificate management 
 document than VOMRS specific one. Maybe one exists? If not, maybe it is 
 something JSPG should think of?

Ian:
But VOMRS explicitly manages the state of the users based on the CA
state (I think) this is not expected at each service?

Tanya:
Again, I am completely aware that managing certificate is a common issue. On 
the
other hand we should
worry about the status of the members for a particular VO, so we have to 
decide how to deal with it.
We do not want to go through the registration process again only because the 
cron
job on the node failed to update
the ca certificate. On the other hand we do not want a VO member with a 
certificate signed by no longer trusted CA to
use grid resources as a valid VO  member. 

====================================================

Karoly:
If a certificate has a VOMS extension, then it has already passed
through a VOMS server, so its issuing CA is trusted by the VO.  Why
would an individual service need to distrust a CA that is otherwise
trusted by a VO that the service belongs to?

Ian:
Because the local service admin must ALWAYS retain the ability to apply local 
policy (even though we hope it 		is rarely exercised) over and above what the 
VO manager might approve of.
====================================================
====================================================

Joni:
 in initial population onwards:
Seems a bit heavy system, I would rather drive for a common directory 
where all CAs reside or if a VO wants a restricted bunch of CAs, it 
should use a separate directory.

Generally there is an expiration date in each CA certificate I would 
keep it there and I would not copy it into any database etc. If the data 
is only in one place there will be no synchronization issues, management 
is easier and there are lower number of system states.

Ian:
Agree

KAroly:
Me too. :-)


Tanya:
Disagree ;). 
Why keeping separate directory is easier that have a denied status in 
database? It requires more actions by the VO administrators: creating the 
directory, managing files, updating them etc  versus just changing the status 
to of the CA certificate.  And everybody can see that the CA is not trusted 
anymore and this is not a script failure to update the directory, but 
conscious decision of VO admin . I think it is nice to have expiration date 
displayed in the WEB UI and not to do openssl for a file every time somebody 
complains about the problem.
====================================================

====================================================

Joni:
My counterproposal a la "keep it simple" would be:
 If service's TRUSTED_CA directory contains a CA cert, it is accepted. 
Unaccepted CAs are removed from this directory. If necessary, service 
 has it's own TRUSTED_CA directory.

Ian:
I think this is equivalent to only implementing 'automated' logic from
sections 2&3 which would get my vote? The option to Deny a cert should
be retained for extreme circumstances. Manually setting expiration date
seems contrived - why is it needed?

Tanya:

I agree with Ian: by default synchronization is automated, each new CA gets an 
"Approved" status,
Denial can be used as an extreme measure (VO admin can not login to a node and 
physically remove the certificate
but he wants all the members with this certificate to be "banned" from using 
grid resources).
Date should  be possible to set only when synchronization is off. (I'll make 
sure that is clearly stated in the
document)

====================================================

====================================================
Joni
If a CA cert expires, it will not work anymore because all the tools 
enforce the expiration. Putting in a new CA cert from the CA re-enables 
the CA. So, the CA certificate update is transparent from the service  point 
of view.

 I really think that if we introduce in addition to CA cert expiration 
 date and GridPMA approval (or VO accepted CAs list) a VOMRS accepted 
 status and expiration date, the system will become very heavy and hard 
 to manage with little gain.


Ian:
hings do get VERY complicated if every body and service can select
authentication roots. Configurable authorization is what is required.

Karoly:


I think VOs may want to have their own personal sets of trusted CAs,
but I don't see why services would need to do that.  I'd simply
put the union of the CAs trusted by the VOs in a single TRUSTED_CA
dir, and let the VOMS/VOMRS stuff weed out those that are not accepted
by individual VOs.

Tanya:
I agree with Karoly. I do not think that it is too complicated when the default
configuration is selected. The more "nonstandard" features you want the more 
headache
you create for yourself. Still I think it is nice when you have a lot of 
possibilities ;).
====================================================

====================================================


Joni:
A small note on one point:

 in CA definition:
 certificates are used to verify digital signatures, not to create them. 
 Also they are not used to create public-private key pairs, they are 
created using public and private keys after their creation.



Tanya:
Thanks, I guess I cut and pasted from the wrong document ;).

====================================================

====================================================

Ian:
Some other points:
How is CA certificate roll-over handled. Is it transparent? i.e 2
different signing keys for the same issuing DN.

Karoly:
It is entirely transparent.  Or at least it is supposed to be. :-)


Tanya:
We completely missed this possibility. We have to think it over. Thanks for 
pointing this out.
====================================================

====================================================
Ian:
Are the signing_policy files considered as relevant?

KAroly
urrently, the VOMS<->LDAP synchronization script uses them to map DNs
downloaded from LDAP into their issuing CA.  As far as I know, this is
the only place where the signing_policy files are used.  It may or may
not be a good idea to check for a DN match in the policy file before
accepting a user---I don't know how these files are maintained, and
(as they are simple text files) there are no cryptographical
assurances that their contents have not been tampered with.

Ian

If we do end up asking the VO manager to 'approve' new certificate
entries please show her the cert fingerprint so she can at least check
it (somewhere - not sure where!)


Tanya:
Have no clue what to do with signing_policy. Could we consider it for the next 
release?
====================================================




IF YOU READ THIS it means that you are extremely interested in VO issues and 
will probably like to add more
comments.
Please, do

Tanya

P.S. I hope I didn't miss anything.

Maria Dimou, IT/GD, Grid Infrastructure Services