Deliverable A.2: Questionnaire on Public Key Infrastructure applications and requirements for the European Academic Networks

Introduction

These are the results collected by the questionnaire on PKI technologies produced in the framework of the TERENA TF-AACE initiative. This survey of the results constitute Deliverable A.2 of TF-AACE.

The data included in this survey have been processed in order to summarize responses and offer a coherent view. If you want to access the raw data, as it was collected from the questionnaire forms, follow this link for participant profiles, and this one for the participant answers.

1 Participant Profiles

1.1 Organization Type

  • University: 5
  • NREN: 3
  • Research Center: 1

1.2 Number of (potential) users

Including those of the affiliated institutions

  • Less than 10,000: 2
  • Between 10,000 and 100,000: 3
  • Between 100,000 and 1 million: 3
  • More than 1 million: 1

1.3 Country

  • Spain: 3
  • Greece: 2
  • Croatia: 1
  • Finland: 1
  • Ireland: 1
  • Multinational (Switzerland based): 1

A Chinese university also filled the questionnaire, although its data has not been taking into account for the survey.

1.4 PKI deployment and status

  • Running services: 3
  • Short-term plans: 2
  • Mid-term plans: 3
  • Long-term (no decision made): 1

1.5 Users of the services

Either actual or intended: final users, other institutions, etc. More than one class of users may be defined for each participant.

  • Final users: 6
  • Server certificates: 3
  • Other institutions: 4
  • Other services: 2
  • Grids: 1

2 Applications

The results indicate the time-frame in which the specified application is planned to be introduced or used. Time-frame values are:

  • Already: Application already in use.
  • Short: Application planned to be used in the short term.
  • Mid: Application planned to be used in the mid term.
  • Long: Application planned to be used in the long term.
  • Never: No plans for using the application, innecesary or unapplicable.

Application

No. of answers

Results

Comments

2.1 E-mail based services

2.1.1 S/MIME 9
Already: 3
Short: 2
Mid: 3
Long: 1
Never: -
  • Depends on when smart cards become common.
  • Testing now, but only supports Netscape products
2.1.2 Delivery or acceptance receipts 5
Already: 1
Short: -
Mid: 4
Long: -
Never: -
  
2.1.3 Secure distribution lists 5
Already: -
Short: 1
Mid: 2
Long: 2
Never: -
  
2.1.4 POP/IMAP over SSL 8
Already: 4
Short: 3
Mid: 1
Long: -
Never: -
  
2.1.5 SMTP over SSL 8
Already: 2
Short: 2
Mid: 3
Long: -
Never: 1
  
2.1.6 Trusted MTA networks 7
Already: 2
Short: -
Mid: 2
Long: 2
Never: 1
  • Main MTA ready for entering Trusted MTA network when available.
2.1.7 Others (please specify) 3
Already: 1
Short: -
Mid: 1
Long: 1
Never: -
  • PGP based end-to-end secure mail as alternative for S/MIME

2.2 Web based services

2.2.1 SSL connections based on server-only authentication 9
Already: 8
Short: 1
Mid: -
Long: -
Never: -
  
2.2.2 Digital signature of Web documents 9
Already: 1
Short: 1
Mid: 4
Long: 2
Never: 1
  • Depends on when smart cards become common.
  • At the moment, it is considered difficult for users to validate. Not useful in actual context.
  • Currently, using PGP
2.2.3 SSL connections based on client authentication 8
Already: 2
Short: 2
Mid: 4
Long: -
Never: -
  • Depends on when smart cards become common...
2.2.4 Digital signature of Web forms 7
Already: -
Short: 1
Mid: 3
Long: 3
Never: -
  • probably in workflow systems
  • Testing
2.2.5 Authentication and authorization infrastructures 9
Already: 4
Short: 1
Mid: 3
Long: 1
Never: -
  • The demand is clear... Plans on piloting...Depends on open source sw available (Shib, Papi...)
  • as grid services becoming web based services
  • LDAP based authentication when possible, local otherwise. No autorizathion infraestructure deployed or in mind.
2.2.6 Others (please specify) 0 n/a  

2.3 XML-enabled Web services

2.3.1 XML-Signature 7
Already: 1
Short: 0
Mid: 4
Long: 2
Never: -
  • A pilot have been done in a HEI with commercial sw.
2.3.2 SAML 7
Already: -
Short: 1
Mid: 4
Long: 1
Never: 1
  • probably in grid applications
2.3.3 Secure SOAP 7
Already: -
Short: 1
Mid: 2
Long: 2
Never: 2
  • in grid applications
2.3.4 Authentication and authorization infrastructures 7
Already: 1
Short: -
Mid: 4
Long: 2
Never: -
  • in grid applications
2.3.5 Others (please specify) 0 n/a  

2.4 Grid applications

2.4.1 GSI-based applications 7
Already: 1
Short: 3
Mid: 0
Long: 1
Never: 2
  • in testbed
2.4.2 OGSA applications 7
Already: 1
Short: 1
Mid: 2
Long: 1
Never: 2
  • in development
2.4.3 Others (please specify) 3
Already: 1
Short: -
Mid: 1
Long: -
Never: 1
  • Integration of OGSA and AAI

2.5 Electronic commerce

2.5.1 Fund transfer systems 7
Already: 1
Short: 1
Mid: 1
Long: -
Never: 4
  • Answers in this and next questions are based in actual context, which may vary.
  • Not our business
2.5.2 Commercial information transfer systems 7
Already: -
Short: -
Mid: 1
Long: 2
Never: 4
  • Not our business
2.5.3 Electronic marketplaces 7
Already: -
Short: -
Mid: -
Long: 1
Never: 6
  • Not our business
2.5.4 Electronic banking 7
Already: 1
Short: 1
Mid: -
Long: -
Never: 5
  • Not our business
2.5.5 Others (please specify) 2
Already: -
Short: -
Mid: -
Long: -
Never: 2
  

2.6 Network layer services

2.6.1 IPsec 8
Already: 4
Short: 1
Mid: 2
Long: 1
Never: -
  • HEIs are deploying distance working with Ipsec
2.6.2 Secure DNS 8
Already: -
Short: 3
Mid: 3
Long: 2
Never: -
  
2.6.3 VPNs 6
Already: 3
Short: 1
Mid: 2
Long: -
Never: -
  • there is a non-PKI based VPN service in operation
  • Testing now
  • IPSEC based
2.6.4 WaveLAN authentication 6
Already: -
Short: 2
Mid: 1
Long: 2
Never: 1
  • EAP-TLS
2.6.5 Others (please specify) 1
Already: -
Short: -
Mid: -
Long: -
Never: 1
  

2.7 Object signing

2.7.1 Secure software distribution 8
Already: -
Short: -
Mid: 4
Long: 2
Never: 2
  
2.7.2 Secure code execution (applets, JavaScript,...) 8
Already: 1
Short: 1
Mid: 2
Long: 2
Never: 2
  
2.7.3 Others (please specify) 1
Already: -
Short: -
Mid: -
Long: -
Never: 1
  

3 Requirements

The results show the average relevance obtained, in the range 0 to 5. 5 means maximum relevance, 0 means null relevance. In the case of assigning a null relevance to a requirement, specific comments were required.

Requirement

No. of answers

Relevance

Comments

3.1 Structural - Support for:

3.1.1 Cross-certificate meshes 9 3.44  
3.1.2 Hierarchies 9 4.44  
3.1.3 Mixed (hierarchy + cross-certificates) 9 3.67  
3.1.4 Bridges 9 3.33
  • our user registration policy requires some additional information on the user, which is usually lost using bridges
3.1.5 Trust path discovery 6 3.17
  • the trusted root CAs are known in advance and their certificates are deployed on the clients
3.1.6 Trust calculation 9 3.78  
3.1.7 Others (please specify) n/a n/a
  • List of trusted root certificates (if the list is relatively short)

3.2 Key management

3.2.1 Key escrow procedures 9 3.78  
3.2.2 Different keypairs for signing and encryption 9 3.33
  • simple user interface is more important
3.2.3 Long-term key survivability 9 3.78
  • useful mostly for document signing; we intend to use PKI primarily for authentication and authorization, so short-term keys are sufficient
3.2.4 Others (please specify) n/a n/a  

3.3 Certificates

3.3.1 Server/client certificates 9 4.89  
3.3.2 Personal certificates 9 4.78  
3.3.3 Role certificates 9 3.67
  • not issued directly by our CA
3.3.4 Group certificates 9 3.11
  • not issued directly by our CA
3.3.5 Attribute certificates 9 4.11
  • for grid authorization
3.3.6 Proxy certificates 9 2.67
  • Not sure about their future
3.3.7 Temporary certificates 9 3.56
  • test x509 for EAP-TLS systems
  • May be overcome by other AAI techniques
3.3.8 Others (please specify) n/a n/a  

3.4 User interfaces

3.4.1 Facilties for user mobility 9 3.00  
3.4.2 Specific tokens for key and certificate storage 9 4.67
  • Mainly smartcard-based tokens
3.4.3 Simplified certificate renewal procedures 9 4.56
  • important with short-term certificates vs. long-term jobs
3.4.4 Others (please specify) n/a n/a  

3.5 Network-enabled credential provision

3.5.1 SACRED 9 2.33
  • Unknown technology
  • Not very clear future
3.5.2 OCR 9 2.89
  • for certificate renewal?!
  • Unknown technology
  • Unknown
3.5.3 GSI-based impersonation 9 2.78
  • Unknown technology
  • Unknown
  • Not very clear future, same as proxy certs
3.5.4 Others (please specify) 7 4.71
  • Interoperability with Kerberos

3.6 Other requirements

3.6.1 Immediate effect of revocations 9 4.00
  • revocation could be temporary due to misuse of resources, soit should be handled by the authorization system
3.6.2 Privacy preservation policies 9 4.11  
3.6.3 Policy management interfaces 9 4.22  
3.6.4 Harmonization with other infrastructures (please detail domains) 9 4.22
  • Kerberos; Linux-Windows interoperability
  • network services
  • Grids, AAI, Videoconferencing, Digital Rights Management
3.6.5 Others (please specify) n/a n/a  

3.7 Enabling technologies

3.7.1 Directories 9 4.56  
3.7.2 Web services 9 4.89  
3.7.3 XKMS 9 2.56
  • need to test its feasibility
  • Unknown
  • Not clear whether it is a hype
3.7.4 Others (please specify) n/a n/a