[gin-ops] Re: [gin-auth] VO name change
Oscar Koeroo
okoeroo at nikhef.nl
Tue Mar 21 04:15:03 CST 2006
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-auth
mailing list