1 / 51

CA issues and the GILDA answer

CA issues and the GILDA answer. Roberto Barbera University of Catania and INFN ICTP/Democritos International Grid School Trieste, 15.02.2006 (Thanks to R. Cecchini and J. Gomez for many slides). Outline. Introduction to grid security The rules for a good Certification Authority

melyssa-mosley
Télécharger la présentation

CA issues and the GILDA answer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CA issues and the GILDA answer Roberto Barbera University of Catania and INFN ICTP/Democritos International Grid School Trieste, 15.02.2006 (Thanks to R. Cecchini and J. Gomez for many slides)

  2. Outline • Introduction to grid security • The rules for a good Certification Authority • (technical!) • The GILDA CA and how to join GILDA • Summary and conclusions ICTP/Democritos International Grid School, Trieste, 15.02.2006

  3. Cryptography • Mathematical algorithms that provide important building blocks for the implementation of a security infrastructure • Symbology • Plaintext: M • Cyphertext: C • Encryption with key K1: E K1(M) = C • Decryption with key K2: D K2(C) = M • Algorithms • Symmetric: K1 = K2 • Asymmetric: K1 ≠ K2 K1 K2 Encryption Decryption M C M ICTP/Democritos International Grid School, Trieste, 15.02.2006

  4. Symmetric Algoritms • The same key is used for encryption and decryption • Advantages: • Fast • Disadvantages: • how to distribute the keys? • the number of keys is O(n2) • Examples: • DES • 3DES • Rijndael (AES) • Blowfish • Kerberos Alice Bob ciao 3$r 3$r ciao Alice Bob ciao 3$r 3$r ciao ICTP/Democritos International Grid School, Trieste, 15.02.2006

  5. public Public Key Algorithms • Every user has two keys: one private and one public: • it is impossible to derive the private key from the public one; • a message encrypted by one key can be decrypted only by the other one. • No exchange of secrets is necessary • the sender cyphers using the public key of the receiver; • the receiver decrypts using his private key; • the number of keys is O(n). • Examples: • Diffie-Helmann (1977) • RSA (1978) Paul John ciao 3$r 3$r ciao Paul John ciao cy7 cy7 ciao Paul keys John keys public private private ICTP/Democritos International Grid School, Trieste, 15.02.2006

  6. X.509 certificates • Public key / Private key pair Text not encrypted Encrypted text Text not encrypted “This test is top secret!” “DG#%$$##/(&)&sdf”$##sdf$%” “This text is top secret!” Encrypt with RSA Decrypt with RSA Public key Private key ICTP/Democritos International Grid School, Trieste, 15.02.2006

  7. One-Way Hash Functions • Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h) • the length of h must be at least 128 bits (to avoid birthday attacks) • given M, it must be easy to calculate H(M) = h • given h, it must be difficult to calculateM = H-1(h) • given M, it must be difficult to find M’ such that H(M) = H(M’) • Examples: • SNEFRU: hash of 128 or 256 bits; • MD4/MD5: hash of 128 bits; • SHA (Standard FIPS): hash of 160 bits. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  8. This is some message Digital Signature This is some message Paul keys = ? Digital Signature public private Digital Signature • Paul calculates the hash of the message • Paul encrypts the hash using his private key: the encrypted hash is the digital signature. • Paul sends the signed message to John. • John calculates the hash of the message and verifies it with A, decyphered with Paul’s publickey. • If hashes equal: message wasn’t modified; Paul cannot repudiate it. Paul This is some message Hash(A) Digital Signature John Hash(B) Hash(A) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  9. Digital Certificates • Paul’s digital signature is safe if: • Paul’s private key is not compromised • John knows Paul’s public key • How can John be sure that Paul’s public key is really Paul’s public key and not someone else’s? • A third party guarantees the correspondence between public key and owner’s identity. • Both A and B must trust this third party • Two models: • PGP: “web of trust”; • X.509: hierarchical organization. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  10. X.509 The “third party” is called Certification Authority (CA). • Issue Digital Certificates for users, programs and machines • Check the identity and the personal data of the requestor • Registration Authorities (RAs) do the actual validation • CA’s periodically publish a list of compromised certificates • Certificate Revocation Lists (CRL): contain all the revoked certificates yet to expire • CA certificates are self-signed ICTP/Democritos International Grid School, Trieste, 15.02.2006

  11. Authentication • Most grid infrastructures including the ones based on EGEE/LCG middleware use X.509 certificates. • How does it work: • Each user, system or service must have a certificate that is used for authentication purposes • In order to identify and authenticate univocally each subject (user, system or service) the certificate must be signed by a trusted authority that asserts that the certificate belongs to the subject • These are the so called certification authorities (CAs) that: • Accept certificate requests and verify the subject identity • Signing the successfully verified certificates • Revoke certificates when needed • Issue lists of revoked certificates • An X.509 authentication infrastructure is called a PKI (Public Key Infrastructure) because its based on public and private keys ICTP/Democritos International Grid School, Trieste, 15.02.2006

  12. X.509 Certificates • An X.509 Certificate contains: • owner’s public key; • identity of the owner; • info on the CA; • time of validity; • Serial number; • digital signature of the CA Structure of a X.509 certificate Public key Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba 8968 Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA Expiration date: Aug 26 08:08:14 2005 GMT Serial number: 625 (0x271) CA Digital signature ICTP/Democritos International Grid School, Trieste, 15.02.2006

  13. More on Authentication • In the grid world one single CA usually covers a predefined geographic region or administrative domain: • Organization • Country • A set of countries • A common trust domain for grid computing has been created to join the several existing certification authorities into a single authentication domain and thus enabling sharing of grid resources worldwide. • The International Grid Trust Federation (IGTF) has been created to coordinate and manage this trust domain. • IGTF is divided in three Policy Management Authorities (PMAs) covering the Asia Pacific, Europe and Americas. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  14. IGTF International Grid Trust Federation (Working to Establish Worldwide Trust for Grids) www.gridpma.org International Grid Trust Federation Asia Pacific PMA Americas PMA AIST Japan APAC Australia ASGCC Taiwan SDG China IHEP China KISTI Korea Naregi Japan BMG Singapore CMSD India HKU Hong Kong NCHC Taiwan Osaka U. Japan USM Malaysia NorduGrid Nordic countries PolishGrid Poland Russian Datagrid Russia SlovakGrid Slovakia DataGrid-ES Spain UK e-Science United Kingdom BelnetGrid Belgium Grid-PK Pakistan FNAL Grid USA GridCanada Canada DOEGrids USA ArmeSFo Armenia IUCC Israel ASCCG Taiwan SeeGrid Europe RMKI Hungary SWITCH Switzerland DFN Germany RDIG Russia LIP CA Portugal CERN CA Switzerland ArmeSFO Armenia CNRS Grid France CyGrid Cyprus CESNET Czech DutchGrid Netherlands GermanGrid Germany HellasGrid Greece GridIreland Ireland INFN CA Italy Belnet Belgium Grid-PK Pakistan SIGNET Slovenia EstonianGrid Estonia AustrianGrid Austria NIIF/HungarNet Hungary IHEP China BalticGrid Europe TR-Grid Turkey DOEGrids USA GridCanada Canada FNAL USA ICTP/Democritos International Grid School, Trieste, 15.02.2006

  15. EUgridPMA(http://www.eugridpma.org) Is a body to establish requirements and best practices for grid identity providers to enable a common trust domain applicable to authentication of end-entities in inter-organisational access to distributed resources. As its main activity the EUGridPMA coordinates a Public Key Infrastructure (PKI) for use with Grid authentication middleware. The EUGridPMA itself does not provide identity assertions, but instead asserts that the certificates issued by the Accredited Authorities meet or exceed the relevant guidelines. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  16. Classic Profile of CA • What is it: • The CA signs and revokes certificates • These are long-term certificates (one year) • The CA has subordinate RAs that just perform the administrative task of checking the subject identity in different organizations or departments • The other possible profile is the SLCS where short lifetime certificates are issued based on other credentials such as kerberos tickets • Each CA issues certificates for its own organization • Still under considerable debate • It may lead to a huge proliferation of CAs causing scalability problems • Advantages: • Is the most known CA profile • A lot of know-how and solutions do exist • Most of the CAs operating today use the classic profile • Is the easiest to support across administrative domains • The SLCS profile is still under discussion • The profile requirements are stable and controlled by EUgridPMA ICTP/Democritos International Grid School, Trieste, 15.02.2006

  17. Classic Profile of a CA • A network of subordinated RAs is necessary to perform the identity verification of the subjects • The RAs will be created at the level of the organizations or at the level of departments: • Operating at university or research centre wide level (more difficult) • Operating at the level of a department or group • The CA can also operate an RA but don’t forget that the physical presence of the subject is required for identity verification • It is fine to have more than one RA per university or research centre if they are operating for different departments • The RAs should be created only upon request, their creation should be user driven. CA Univ A Univ B Univ C Univ D Univ E Univ F Univ G RA RA RA RA RA RA RA RA ICTP/Democritos International Grid School, Trieste, 15.02.2006

  18. Classic profile of a CA • How to obtain a certificate: Request A certificate request is performed The user identify is confirmed by the RA The certificate is used as a key to access the grid The certificate is issued by the CA ICTP/Democritos International Grid School, Trieste, 15.02.2006

  19. Certificate issuance in more detail Request with public key 3.Manual transfer of the request 1.Request by the user Private/Public key pair is generated private key is kept on the user side 5.Manual transfer of the certificate CA server 2.Identity verification by an RA 6.Download of the certificate CA private key 4.CA signature Signing machine (off-line) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  20. Revocation Lists • The CAs have the obligation of issue Certificate Revocation Lists (CRL) • The CRLs contain: • a list of the revoked certificates • the date when they were issued • the end date • CRLs are signed with the CA private key • The CRLs must be published so that the relying parties can check the validity of the certificates • Usually available through http • When a CRL expires all the issued certificates will fail until a new CRL becomes available. • THIS MUST NOT HAPPEN !!! ICTP/Democritos International Grid School, Trieste, 15.02.2006

  21. The Classic CA Profile • There should be a single Certification Authority (CA) organisation per country, large region or international organization. • Provide a short number of stable CAs • CAs must be operated as a long-term commitment • They should remain operational after the end of the project • A network of Registration Authorities (RA) for each CA is responsible for authentication of requests • The CA will handle the task of: • issuing CRLs • signing Certificates/CRLs • revoking Certificates ICTP/Democritos International Grid School, Trieste, 15.02.2006

  22. CA profile: Identity • Any single subject distinguished name (DN) must be linked to one and only one entity • DNs must be unique • Over the entire lifetime of the CA a DN must not be linked to any other entity • One entity can have more than one subject name for different key usages • One user can have more than one certificate • One server can have more than one certificate • Certificates must not be shared among end entities • A certificate cannot be shared with other users • CAs and RAs must immediately revoke these certificates when such a violation of the CP/CPS is detected ICTP/Democritos International Grid School, Trieste, 15.02.2006

  23. CA profile: Identity vetting • The CA must define the role of the registration authority (RA) • What it does and how it does it • RAs are responsible for the identity vetting of all end-entities such as: • natural persons • network entities • In order for an RA to validate the identity of a person, the subject should: • contact the RA face-to-face • present photo-id and/or valid official documents • showing that the subject is an acceptable end entity as defined in the CP/CPS document of the CA (for instance that the subject is an academic user) • showing that the subject is an acceptable end entity as defined in the RA operations rules (for instance that the subject belongs to the RA organization) • For host or service certificate requests, the RA should validate the identity of the person in charge of the specific entities using a secure method • For instance accepting only requests signed by the system manager using a validate certificate • The RA should validate the association of the certificate signing request with the subject • The certificate content must be related with the user ICTP/Democritos International Grid School, Trieste, 15.02.2006

  24. CA profile: Operational requirements • The CA computer, where the signing of the certificates will take place, needs to be a dedicated machine • running no other services than those needed for the CA operations • The CA computer must be located in a secure environment • access is controlled, limited to specific trained personnel • must be kept disconnected from any kind of networks at all times !!! • If the CA computer is equipped with at least a FIPS 140-2 level 3 Hardware Security Module or equivalent, to protect the CA’s private key, the CA computer can be connected to a highly protected/monitored network • possibly accessible from the Internet • the secure environment must be documented and available for audit • extremely expensive (more than 7000 Euro) • The CA Key must have a minimum length of 2048 bits • for CAs that issue end-entity certificates the CA certificate lifetime: • must be no less than two times the maximum life time of an end entity certificate • should not be more than 20 years ICTP/Democritos International Grid School, Trieste, 15.02.2006

  25. CA profile: Operational requirements • The private key of the CA must be protected with a pass phrase • of at least 15 characters • known onlyby specific personnel of the Certification Authority • except in the case of an HSM where an equivalent level of security must be maintained • some CAs protect the private key with two passwords known by two different persons so that for signing operations the agreement of both persons is necessary • Copies of the encrypted private key must be kept on offline mediums in secure places where access is controlled • access controlled means that only CA authorized personnel should be able to have access to the CA private key (even in encrypted format) • for instance maintenance or cleaning personnel must be accompanied at all times when in the room where the keys are stored or the machines installed • preferably the CA keys should be stored in fire-proof safes • an off-site backup is advisable • the offline mediums should be preferably read only ICTP/Democritos International Grid School, Trieste, 15.02.2006

  26. CA profile: Operational requirements • The CA also maintains online systems: • used as repository of certificates, CRLs, documentation etc • used to receive and process requests and to communicate with the RAs • usually this is a single machine running the CA management software and a web server to support the repository • Also this machine needs to be kept in a secure environment, advise: • firewall protected • running only the essential services • services must be kept updated (security) • physical security ICTP/Democritos International Grid School, Trieste, 15.02.2006

  27. CA profile: CP/CPS Identification • Every CA must have a Certification Policy and Certificate Practice Statement • For new CAs the CP/CPS documents must be structured as defined in RFC 3647 • This is a new format. Most CP/CPS were written in RFC 2527 • Examples: • PkirisGrid • AustrianGrid • Major CP/CPS changes must be: • announced to the accrediting PMA • approved before signing any certificates under the new CP/CPS • All the CP/CPS under which valid certificates are issued must be available on the web (many examples can be found at http://www.eugridpma.org/members/index.php) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  28. CA profile: Certificate and CRL • The accredited authority must publish a X.509 certificate as a root of trust. • The CA certificate must have the extensions keyUsage and basicConstraints marked as critical. • The authority shall issue X.509 certificates to end-entities based on cryptographic data: • generated by the applicant • or based on cryptographic data that can be held only by the applicant on a secure hardware token • The EE keys must be at least 1024 bits long • The EE certificates must have a maximum lifetime of 1 year plus 1 month • The end-entity certificates must be in X.509v3 format and compliant with RFC3280 • The message digests of the certificates and CRLs must be generated by a trustworthy mechanism, like SHA1 • MD5 must not be used ICTP/Democritos International Grid School, Trieste, 15.02.2006

  29. CA profile: Certificate and CRL • If a commonName (CN) component is used as part of the subject DN, it should contain an appropriate presentation of the actual name of the end-entity. • In the certificate extensions: • a Policy Identifier must be included and must contain an OID and an OID only • CRLDistributionPoints must be included and contain at least one http URL • keyUsage must be included and marked as critical • basicConstraints should be included, and when included it must be set to ‘CA: false’ and marked as critical • if an OCSP responder, operated as a production service by the issuing CA, is available, AuthorityInfoAccess must be included and contain at least one URI • for certificates bound to network entities, a FQDN shall be included as a dnsName in the SubjectAlternativeName ICTP/Democritos International Grid School, Trieste, 15.02.2006

  30. CA profile: Revocation • The CA must publish a CRL containing the numbers of the revoked certificates • When a request for certificate revocation is received: • the CA must react as soon as possible, • but within one working day • After each revocation a CRL must be issued immediately • For CAs issuing certificates to end-entities: • the maximum CRL lifetime must be at most 30 days • the CA must issue a new CRL at least 7 days before expiration and immediately after a revocation • The CRLs must be published in a repository at least accessible via the World Wide Web, as soon as issued • Properly authenticated revocation requests can be made by: • end-entities • registration Authorities • the CA itself • Others can request revocation if they can sufficiently prove compromise or exposure of the associated private key • End-entities must request revocation if: • the private key pertaining to the certificate is lost or has been compromised • if the data in the certificate are no longer valid ICTP/Democritos International Grid School, Trieste, 15.02.2006

  31. CA profile:audits • The CA must record and archive: • all requests for certificates • all the issued certificates • all the requests for revocation • all the issued CRLs • the login/logout/reboot of the issuing machine. • These CA records must be: • kept for at least three years. • made available to external auditors in the course of their work as auditor. • Each CA must accept being audited by other accredited CAs to verify its compliance with the rules and procedures specified in its CP/CPS document. • The CA should perform operational audits of the CA/RA staff at least once per year. • A list of CA and RA personnel should be maintained and verified at least once per year. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  32. CA profile: privacy and confidentiality • Accredited CAs must define a privacy and data release policy compliant with the relevant national legislation • check you national legislation • It may require the explicit authorization of the subject to store or publish some of its data identification and contact data • The CA is responsible for recording, at the time of validation, sufficient information regarding the subscribers to identify the subscriber. • the CA is not required to release such information unless provided by a valid legal request according to national laws applicable to that CA. • The CA must maintain a record of the identifications performed and the correspondence with the certificate DN ICTP/Democritos International Grid School, Trieste, 15.02.2006

  33. CA profile: compromise and disaster • The CA must have an adequate compromise and disaster recovery procedure, and be willing to discuss this procedure in the PMA. • store the CA keys and backups in secure offsite locations • have machines available that can be reinstalled to serve as signing machine or CA web server • describe the procedure to recover and reinstall the systems • have a backup location at a different geographic location (in case of natural disaster) • The procedure need not be disclosed in the policy and practice statements. • The CA should make a reasonable effort to make sure that end-entities realize the importance of properly protecting their private data. • users must be informed of their obligations • providing a short list of obligations and security routines can be useful • It’s upon the user to protect his private key with a pass phrase at least 12 characters long. ICTP/Democritos International Grid School, Trieste, 15.02.2006

  34. RA operations • The operation of the RAs must be: • in accordance with the CA CP/CPS • defined in a document for each RA • The RA operation in general: • Each RA must have one responsible person (manager) • A deputy is advisable • The manager can nominate one or more operators • Both the manager and the operators can authorize requests • All RA personnel must be trained in CA/RA operations and security • The selection method of the personnel should be defined • The CA must be informed officially of any change of RA personnel (eg: a letter signed and stamped) • The first manager must be identified/authenticated by the CA in person • Each RA should have a unique namespace (subject DN prefix) to avoid DN name collisions • The community supported by the RA must be well defined • The method used to identify subjects must be fully described including the enforcement of any additional requirements imposed by the CA or by the RA (eg. relation with an organization) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  35. CA/RA namespaces • The namespace definition is of the responsibility of the CA however depending on this definition the RA can also be involved eg. (just an example based on the LIP CA namespace ...) • /C=PT/O=LIPCA/ • CA prefix should be unique across CAs • /C=PT/O=LIPCA/O=UMINHO • The second /O= designates the organization of the subject and also the RA • /C=PT/O=LIPCA/O=UMINHO/OU=DI • The /OU=DI in the LIP case is optional and can be used to identify a department within the organization • It is used to designate an RA within the organization when an organization has multiple RAs ICTP/Democritos International Grid School, Trieste, 15.02.2006

  36. CA/RA namespaces • About the CN and full DN: • /C=PT/O=LIPCA/O=UMINHO/OU=DI/CN=Jose A Sousa • each DN must be unique: • Long enough to avoid collisions • Add something (number,... ) when duplications are found • Possibly using the person full name is the best option • each DN must be bound to the same subject for the lifetime of the CA • The CN must have a clear direct relation with the DN • Don’t forget that the certificates are for grid computing, don’t create names (or extensions) that may create problems for the middleware • Please don’t use accents • Some characters may have special meanings for the applications (eg. The “-” character is recognized by globus as an wildcard) • Some characters are not allowed (eg. “/” and “.” in user certificates) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  37. Renewal • Two types of renewals: • End entities certificate renewals • CA certificate renewals • End entities: • The certificates maximum lifetime is 1 year + 1 month • The idea is that at the end of the year (12th month) a new certificate is issued • Users (EE) should be warned about the coming expiration and the need to renew • Since the new certificate will be issued at the end of the 12th month (or beginning of the 13th) there will be an overlap of two certificates: • this is used to avoid a situation where the certificate will expire rendering the service or the user without grid access • don’t forget there are users submitting jobs that may take days or weeks • during this period there will be two certificates with the same DN • Don’t revoke a certificate to issue a new one unless the certificate has been compromised or the user has ceased his activity or liaison which entitles him to have a certificate ICTP/Democritos International Grid School, Trieste, 15.02.2006

  38. Renewal • End entities: • During a renewal it is not required to make the EE to pass through the identification procedure: • This is a big advantage for both the EE and the RA • However a maximum renewal number without identification is advisable (for instance: every two years the EE must pass through the identification again) • However the relation with the organization should still be performed (if this requirement is being used) • In order not to pass through the identification the renewal request must be signed with the user certificate, examples: • Email signed with user certificate • CA/RA Web interface that would identify the user certificate • If the user certificate expires before renewal the procedure for a new certificate must be followed ICTP/Democritos International Grid School, Trieste, 15.02.2006

  39. Renewal • CA certificate: • This is a delicate procedure • A new CA certificate must be issued before the old one expires • The overlap time must be at least equal to the largest possible lifetime of the EE certificates (1 year + 1 month) • The new CA must have a higher serial number !!! Including in the file names of type hash.n, hash.rn etc • Once the new certificate is issued the old one cannot be used to sign new certificates • You cannot have EE certificates with larger lifetimes than the lifetime of the signing CA certificate • The old CA must still be around to issue CRLs and authenticate old EE certificates • The new CA distribution kit must be created and publish by IGTF • The new kit must be installed everywhere • Make the CA lifetime long enough so that you don’t need to do this frequently • 20 years is the maximum with 2048 bit keys • Probably 4096 bit keys are a better option (currently only two CAs use that) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  40. CA management software • The commercial solutions are very expensive • Most classic CAs are based on open source software • OpenCA • Custom solutions based on OpenSSL • OpenCA is powerful but also complex and difficult to customize • The Spanish Rediris CA has developed a custom solution based on OpenSSL that will be packaged and made available • A clone of the Italian INFN CA is used by GILDA and can be distributed • Typical architecture: • based on web interfaces • the CA maintains • a server connected to the network • a workstation to sign certificates disconnected from the network • the subscribers use the server web interface to request, download, renew, revoke certificates • The RAs use the server web interface to authorize or refuse certificates request and request revocations • The CA uses the server to obtain requests that are then processed in the signing workstation ICTP/Democritos International Grid School, Trieste, 15.02.2006

  41. CA management software • The web based CA management software is easy to use however you should consider it carefully: • Compatibility with different browsers can be a problem • Sometimes even a different version of a supported browser breaks things • Test the software carefully with as much browsers as possible • Security can be a concern when the machines from which the certificate requests are performed are public machines in a public terminal room • Sometimes people may not take all necessary precautions when generating the keys (namely protecting the private key with a password) • Exporting the certificate from the browser to the disk and converting it from pkcs12 to PEM can be a problem for certain users • You may consider having a backup solution to perform the certificate requests not based on browsers ICTP/Democritos International Grid School, Trieste, 15.02.2006

  42. GILDA CA(https://gilda.ct.infn.it/CA) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  43. Join GILDA as a User(https://gilda.ct.infn.it/users.html) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  44. GILDA User Certificates ICTP/Democritos International Grid School, Trieste, 15.02.2006

  45. GILDA VOMS (1/4)(https://voms.ct.infn.it:8443/voms/gilda/webui/user/create) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  46. GILDA VOMS (2/4) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  47. GILDA VOMS (3/4) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  48. GILDA VOMS (4/4) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  49. Join GILDA as a Site(https://gilda.ct.infn.it/sites.html) ICTP/Democritos International Grid School, Trieste, 15.02.2006

  50. GILDA Host Certificates ICTP/Democritos International Grid School, Trieste, 15.02.2006

More Related