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

Olle Mulmo mulmo at pdc.kth.se
Mon Apr 24 08:02:27 CDT 2006 

Oscar,

I just got a flashback: in the openssl config file you should be able  
to alter how openssl displays various RDNs as text (UID vs USERID,  
and so on). I don't have time to look up the details for you right  
now, but it's described in one of the text files under /usr/share/doc/ 
openssl on most Linuxes (OID mappings).

/Olle

On Apr 24, 2006, at 12:24, Oscar Koeroo wrote:

> Hi Cindy and others,
>
> Concerning the recent experiences within GIN regarding VOMS,  
> certificates, CAs and things that link to these terms, I've written  
> a small document about this.
>
>
>    Oscar
>
>
>
> Cindy Zheng wrote:
>
>> Thank you very much, Oscar!
>>
>>
>>> -----Original Message-----
>>> From: owner-gin-ops at ggf.org [mailto:owner-gin-ops at ggf.org] On  
>>> Behalf Of Oscar Koeroo
>>> Sent: Thursday, March 23, 2006 12:19 AM
>>> To: zhengc at sdsc.edu
>>> Cc: 'Vincenzo Ciaschini'; gin-auth at ggf.org; gin-ops at ggf.org
>>> Subject: Re: [gin-ops] Re: [gin-auth] VO name change
>>>
>>>
>>> I'll make a small doc on the current experiences.
>>>
>>>    Oscar
>>>
>>>
>>> Cindy Zheng wrote:
>>>
>>>
>>>> Cool! It works!
>>>> Thank you, Oscar and Vincenzo, for the quick resolution!
>>>>
>>>> We need to document all the issues in our GIN experiment. Since  
>>>> you guys know best what's going on with this,
>>>> would you mind to lead the effort to document this issue?
>>>> All suggestions and volunteers are welcome! :-)
>>>>
>>>> Thanks again,
>>>>
>>>> Cindy
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: owner-gin-auth at ggf.org [mailto:owner-gin-auth at ggf.org] On  
>>>>> Behalf Of Oscar Koeroo
>>>>> Sent: Wednesday, March 22, 2006 8:21 AM
>>>>> To: zhengc at sdsc.edu
>>>>> Cc: gin-auth at ggf.org; gin-ops at ggf.org
>>>>> Subject: Re: [gin-ops] Re: [gin-auth] VO name change
>>>>>
>>>>>
>>>>> Hi Cindy & all,
>>>>>
>>>>> We found the problem. The UID/USERID issue in the user DN is  
>>>>> solved in the VOMS code at all places *but* not for the CA DNs.
>>>>> It is regarded odd to have a UID/USERID in the DN of the CA...
>>>>>
>>>>> So our tmp workaround is to change the stored DN for your
>>> CA. We have
>>>>> done this for you now. The problem is that the software could  
>>>>> clean the CA list in the database and introduce a problem...
>>>>>
>>>>> A newer version of the VOMS daemon will be released and  
>>>>> installed on my machine when this bug is ready. The problem is  
>>>>> located only at the serverside, no need to change your clients.
>>>>>
>>>>>
>>>>> Have a go for it, though until the newer version installed I  
>>>>> can't give you to much support on this, because it could  
>>>>> consume to much of my (personal) time. :-)
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>>   Oscar
>>>>>
>>>>>
>>>>> Cindy Zheng wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>
> <Cert-probs-GIN.pdf>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1427 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/gin-auth/attachments/20060424/c1390aab/attachment.bin

More information about the gin-auth mailing list