[gin-ops] Re: [gin-auth] VO name change

Cindy Zheng zhengc at sdsc.edu
Tue Mar 21 18:52:20 CST 2006


Thank you, Oscar! 

But I'm still getting the same error. Either this was not 
the cause, or there are additional problems. Could you 
check your log and see if any clues?

I agree that this case is special in the sense of not
IGTF accredited CA. But, I think we can benefit from dealing
with this, either as a case of non-IGTF CA or as a case of
mixed GT versions. In the near term, these issues will show
up again as more grids joining GIN.

I feel the same as you do - the incompatibility of the DN 
format is annoying. I'm not a security expert. In my naive 
opinion, it would work best if globus software can take care 
of this somehow. I would like to hear what you and others 
think is the best solution. Hopefully, these problems and
discussions can resolve to some concret recommendations or
work plans. Perhaps this can be one of many lessons we learn 
thru our interoperation?

Below is the output of voms-proxy-init. Also "grid-proxy-init",
just to verify my .globus setup and give you the time to 
locate the corresponding log entries.

[zhengc at rocks-52 ~]$ voms-proxy-init --debug --voms gin.ggf.org
Detected Globus version: 22
Unspecified proxy version, settling on Globus version: 2
Number of bits in key :512
Using configuration file /opt/glite/etc/vomses
Using configuration file /opt/glite/etc/vomses
Files being used:
 CA certificate file: none
 Trusted certificates directory : /etc/grid-security/certificates
 Proxy certificate file : /home/zhengc/.globus/.proxy
 User certificate file: /home/zhengc/.globus/usercert.pem
 User key file: /home/zhengc/.globus/userkey.pem
Output to /home/zhengc/.globus/.proxy
Your identity: /C=US/O=SDSC/OU=SDSC/CN=Cindy Zheng/USERID=zhengc
Enter GRID pass phrase:
Creating temporary proxy to /tmp/tmp_x509up_u502_2448
...........++++++++++++
...................................++++++++++++
 Done
Contacting  kuiken.nikhef.nl:15050
[/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=kuiken.nikhef.nl] "gin.ggf.org"
Error: gin.ggf.org: User unknown to this VO.
[zhengc at rocks-52 ~]$ grid-proxy-init
Your identity: /C=US/O=SDSC/OU=SDSC/CN=Cindy Zheng/UID=zhengc
Enter GRID pass phrase for this identity:
Creating proxy ............................ Done
Your proxy is valid until: Wed Mar 22 04:24:18 2006

Cindy

> -----Original Message-----
> From: owner-gin-ops at ggf.org [mailto:owner-gin-ops at ggf.org] On 
> Behalf Of Oscar Koeroo
> Sent: Tuesday, March 21, 2006 2:15 AM
> To: Cindy Zheng
> Cc: gin-auth at ggf.org; gin-ops at ggf.org
> Subject: Re: [gin-ops] Re: [gin-auth] VO name change
> 
> 
> Hi Cindy,
> 
> I now regard your registration in the VOMS db as special, 
> with respect 
> to the instant trust in your CA and this little change.
> Which means that I've updated your DN in the database with the UID to 
> USERID substring change.
> 
> It seems that it is up to the software on how they can either 
> construct 
> a DN to UID or USERID. According to my Google searches the UID is the 
> prevailed string representation for that part of your DN in your 
> certificate which means that something (the used software that 
> constructs a DN from a X.509 cert to do the simple string 
> compare) needs 
> investigation on possible incompatibility between the two 
> repesentations.
> Perhaps I'm just negatively paranoid ofcourse, but this issue 
> could hit 
> us again when other members would have an serialNumber or SN 
> in their DN :-)
> 
> My personal feelings towards the CAs in general is still unchanged in 
> the matter of avoiding dubious fields like UID/USERID, 
> emailAddress/Email and such in a DN which is used in simple 
> stringcompare operations in numerous parts of middleware.
> 
> 
> cheers,
> 
>     Oscar
> 
> 
> 
> Cindy Zheng wrote:
> 
> >Thank you, Oscar! I agree that we should have in-depth
> >discussion on this issue.
> >Meanwhile, can we also have a temporary solution?
> >Since double entry does not work for your environment, 
> >how about change UID to USERID in my DN string in your
> >voms db? Welcome any better ideas and solutions.
> >
> >Thanks again,
> >
> >Cindy 
> >
> >  
> >
> >>-----Original Message-----
> >>From: owner-gin-ops at ggf.org [mailto:owner-gin-ops at ggf.org] On 
> >>Behalf Of Oscar Koeroo
> >>Sent: Friday, March 17, 2006 6:20 PM
> >>To: zhengc at sdsc.edu
> >>Cc: gin-auth at ggf.org; gin-ops at ggf.org; Olle Mulmo; Dane Skow; 
> >>David Groep
> >>Subject: [gin-ops] Re: [gin-auth] VO name change
> >>
> >>
> >>Hi Cindy,
> >>
> >>I wish to help here, but this seems be a point where 
> interoperability 
> >>needs to be noted (done), fixed/solved and documented.
> >>I know of the existance of UID and USERID, now I know where 
> >>my confusion 
> >>comes from (I could remember if it was UID or USERID).
> >>
> >>I think that a double entry in the VOMS DB is not the way to go.
> >>
> >>Perhaps David Group, Dane Skow or Olle Mulmo can give a 
> >>better judgement 
> >>on what to do.
> >>Personally I do not like the UID/USERID option for a bit in 
> the DN of 
> >>personal certificate. Especially since it doesn't give you any 
> >>identificational value if you cross a domain that has you 
> registered 
> >>differently (by their local policy).
> >>
> >>
> >>    Oscar
> >>
> >>
> >>
> >>Cindy Zheng wrote:
> >>
> >>    
> >>
> >>>Thanks, Oscar, for checking!
> >>>
> >>>The DN is the same, but "seen" differently by different 
> >>>versions of GT. GT2 formats it as USERID= and GT3&4 
> >>>formats it as UID=. I learned this, since PRAGMA testbed 
> >>>sites are running a mixture of GT2,3,4.
> >>>What we do in PRAGMA testbed is to add a DN in both format
> >>>in the gridmap file, so even when GT get upgraded, you 
> >>>don't have to worry about it. Perhaps you can do the same?
> >>>
> >>>Let me know and I can then test it again.
> >>>
> >>>Our SDSC CA admin also pointed out that a signing_policy 
> >>>file which will recognize the OID 0.9.2342.19200300.100.1.1
> >>>as either UID or USERID is linked off the CA web page:
> >>>http://www.sdsc.edu/CA/.
> >>>
> >>>Thanks,
> >>>
> >>>Cindy
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>-----Original Message-----
> >>>>From: Oscar Koeroo [mailto:okoeroo at nikhef.nl] 
> >>>>Sent: Friday, March 17, 2006 3:19 AM
> >>>>To: Cindy Zheng
> >>>>Cc: gin-auth at ggf.org; gin-ops at ggf.org
> >>>>Subject: Re: [gin-auth] VO name change
> >>>>
> >>>>
> >>>>Hi,
> >>>>
> >>>>Have look at your DN
> >>>>
> >>>>/C=US/O=SDSC/OU=SDSC/CN=Cindy Zheng/USERID=zhengc
> >>>>
> >>>>and compare it to:
> >>>>"/C=US/O=SDSC/OU=SDSC/CN=Cindy Zheng/UID=zhengc" .gin.ggf.org
> >>>>
> >>>>This will never match :-)
> >>>>Please use only one certificate.
> >>>>
> >>>>cheers,
> >>>>
> >>>>	Oscar
> >>>>
> >>>>
> >>>>
> >>>>Cindy Zheng wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>Hi, Oscar,
> >>>>>
> >>>>>I modified the VO name in the vomses file, but I get
> >>>>>"user unknown to this VO" when run voms-proxy-init. 
> >>>>>Did you add SDSC cert files in the new VO server?
> >>>>>Or did I missed something? Here is the vomses file 
> >>>>>and voms-proxy-init output:
> >>>>>
> >>>>>[zhengc at rocks-52 vomsdir]$ cat /opt/glite/etc/vomses/gin.ggf.org 
> >>>>>"gin.ggf.org" "kuiken.nikhef.nl" "15050"
> >>>>>"/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=kuiken.nikhef.nl" 
> >>>>>          
> >>>>>
> >>"gin.ggf.org"
> >>    
> >>
> >>>>>[zhengc at rocks-52 vomsdir]$ voms-proxy-init --debug --voms 
> >>>>>          
> >>>>>
> >>gin.ggf.org
> >>    
> >>
> >>>>>Detected Globus version: 22
> >>>>>Unspecified proxy version, settling on Globus version: 2
> >>>>>Number of bits in key :512
> >>>>>Using configuration file /opt/glite/etc/vomses
> >>>>>Using configuration file /opt/glite/etc/vomses
> >>>>>Files being used:
> >>>>>CA certificate file: none
> >>>>>Trusted certificates directory : /etc/grid-security/certificates
> >>>>>Proxy certificate file : /home/zhengc/.globus/.proxy
> >>>>>User certificate file: /home/zhengc/.globus/usercert.pem
> >>>>>User key file: /home/zhengc/.globus/userkey.pem
> >>>>>Output to /home/zhengc/.globus/.proxy
> >>>>>Your identity: /C=US/O=SDSC/OU=SDSC/CN=Cindy Zheng/USERID=zhengc
> >>>>>Enter GRID pass phrase:
> >>>>>Creating temporary proxy to /tmp/tmp_x509up_u502_21548
> >>>>>.......++++++++++++
> >>>>>...........................................++++++++++++
> >>>>>Done
> >>>>>Contacting  kuiken.nikhef.nl:15050
> >>>>>[/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=kuiken.nikhef.nl] 
> >>>>>          
> >>>>>
> >>"gin.ggf.org"
> >>    
> >>
> >>>>>Error: gin.ggf.org: User unknown to this VO.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: owner-gin-auth at ggf.org [mailto:owner-gin-auth at ggf.org] 
> >>>>>>On Behalf Of Oscar Koeroo
> >>>>>>Sent: Tuesday, March 14, 2006 6:09 AM
> >>>>>>To: gin-auth at ggf.org
> >>>>>>Subject: [gin-auth] VO name change
> >>>>>>
> >>>>>>
> >>>>>>Hello everybody,
> >>>>>>
> >>>>>>The GIN VO name has been change from 'GIN-GGF-ORG' to 
> >>>>>>'gin.ggf.org' with 
> >>>>>>the approval of the security area directroy to use the 
> >>>>>>ggf.org domain name.
> >>>>>>All other configurations and registration have stayed 
> >>>>>>            
> >>>>>>
> >>persistently. 
> >>    
> >>
> >>>>>>Which means, the same portnumbers do apply on the same server 
> >>>>>>with the 
> >>>>>>same certificate.
> >>>>>>
> >>>>>>Though the web site as been move to:
> >>>>>>https://kuiken.nikhef.nl:8443/voms/gin.ggf.org/
> >>>>>>
> >>>>>>The configuration for the vomses file has change to:
> >>>>>>
> >>>>>>"gin.ggf.org" "kuiken.nikhef.nl" "15050" 
> >>>>>>"/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=kuiken.nikhef.nl" 
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>"gin.ggf.org"
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>>And also the legacy support interface for mkgridmap has also 
> >>>>>>changed with the URL change to:
> >>>>>>group vomss://kuiken.nikhef.nl:8443/voms/gin.ggf.org  
> .gin.ggf.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>  Oscar - /gin.ggf.org/Role=VO-Admin
> >>>>>>
> >>>>>>
> >>>>>>Oscar Koeroo wrote:
> >>>>>>
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>which means that I'll change the GIN-GGF-ORG VO name to:       
> >>>>>>>"gin.ggf.org"
> >>>>>>>... if one or both security area directors approve with the 
> >>>>>>>    
> >>>>>>>
> >>>>>>>         
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>change and 
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>use of the "ggf.org" domain as a suffix to the GIN VO.
> >>>>>>>
> >>>>>>> Oscar
> >>>>>>>
> >>>>>>>
> >>>>>>>Von Welch wrote:
> >>>>>>>
> >>>>>>>    
> >>>>>>>
> >>>>>>>         
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>>>Works for me.
> >>>>>>>>
> >>>>>>>>Von
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>On Mar 13, 2006, at 12:42 PM, Olle Mulmo wrote:
> >>>>>>>>
> >>>>>>>>      
> >>>>>>>>
> >>>>>>>>           
> >>>>>>>>
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>>>FYI,
> >>>>>>>>>
> >>>>>>>>>This was discussed (again) at two consecutive EGEE 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>meetings at CERN  
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>last week, ending in the draft text proposed below.
> >>>>>>>>>
> >>>>>>>>>/Olle
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>VO Naming
> >>>>>>>>>---------
> >>>>>>>>>The VO name is a string, used to represent the VO in all 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>interactions
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>with grid software, such as in expressions of policy 
> >>>>>>>>>                  
> >>>>>>>>>
> >>and access  
> >>    
> >>
> >>>>>>>>>rights.
> >>>>>>>>>
> >>>>>>>>>The VO name MUST be formatted as a subdomain name as 
> >>>>>>>>>                  
> >>>>>>>>>
> >>specified in
> >>    
> >>
> >>>>>>>>>RFC 1034 section 3.5. The VO Manager of a VO using a 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>thus-formatted  
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>name
> >>>>>>>>>MUST be entitled to the use of this name, when 
> >>>>>>>>>                  
> >>>>>>>>>
> >>interpreted as a  
> >>    
> >>
> >>>>>>>>>name in the Internet Domain Name System.
> >>>>>>>>>This entitlement MUST stem either from a direct 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>delegation of the  
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>corresponding name in the Domain Name System by an 
> accredited  
> >>>>>>>>>registrar for
> >>>>>>>>>the next-higher level subdomain, or from a direct 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>delegation of the
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>equivalent name in the Domain Name System by ICANN, or 
> >>>>>>>>>                  
> >>>>>>>>>
> >>from the  
> >>    
> >>
> >>>>>>>>>consent
> >>>>>>>>>of the administrative or operational contact of the 
> >>>>>>>>>                  
> >>>>>>>>>
> >>next-higher  
> >>    
> >>
> >>>>>>>>>equivalent
> >>>>>>>>>subdomain name for that VO name that itself is registered 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>with such an
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>accredited registrar.
> >>>>>>>>>
> >>>>>>>>>Considering that RFC1034 section 3.5 states that both 
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>upper case  
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>>>>>and lower
> >>>>>>>>>case letters are allowed, but no significance is to be 
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> >>>>>>attached to  
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>>>the case,
> >>>>>>>>>but that today the software handling VO names may 
> >>>>>>>>>                  
> >>>>>>>>>
> >>still be case  
> >>    
> >>
> >>>>>>>>>sensisitive,
> >>>>>>>>>all VO names MUST be entirely in lower case.
> >>>>>>>>>
> >>>>>>>>>        
> >>>>>>>>>
> >>>>>>>>>             
> >>>>>>>>>
> >>>>>>>>>                  
> >>>>>>>>>
> 





More information about the gin-ops mailing list