semi合集-English.pdf - 第3384页

SEMI E132.1-0305 © SEMI 2005 11 Client Equipment Client Hello ServerHello Certifi cate CertificateR equest Certificate ClientKey Exchange CertificateVerify ChangeCiphe rSpec ServerH elloDone Server public key certificate…

100%1 / 7923
SEMI E132.1-0305 © SEMI 2005 10
Table 7 Example Operation Binding Table
SOAPAction <the SOAPAction HTTP header value to be used for this operation>
Input Headers (WSDL Message, Required)
<the name of the WSDL message providing input headers, and whether or
not the headers are required>
Output Headers (WSDL Message, Required)
<the name of the WSDL message providing output headers, and whether or
not the headers are required>
Table 8 Example PortType Operation Table
Input Message Name <WSDL message name used as input for the WSDL port type operation>
Output Message Name <WSDL message name used as output for the WSDL port type operation>
7 SEMI E132 Authentication Mapping to SSL
7.1 SSL Overview
7.1.1 This section describes the use of SSL security protocol and supporting technology to implement the
authentication scheme described in SEMI E132. SSL is application protocol independent and transparently supports
any higher layered transport protocols such as SOAP over HTTP.
7.1.2 Figure 3 presents the basic message flow (handshake) of SSL to establish a secure connection and how it
maps to the SEMI E132 authentication messages, please refer to the SSL documentation referenced in ¶4.4 for
complete specification on SSL. This specification defines several restrictions on the capabilities of SSL to the
minimum necessary to support SEMI E132 authentication. These restrictions are described in more detail in the
following section.
7.1.3 SEMI E132 Restrictions on SSL
7.1.3.1 X.509 v3 public key certificates as defined by RFC 2459 must be used to establish equipment and client
identities, see X.509 documentation referenced in ¶4.4 for complete details of X.509 structure and content. The
certificate is sent when required during the SSL handshake.
7.1.3.2 Mutual authentication is required. Equipment shall always send its certificate and request for the client’s
certificate as part of the SSL handshake. Correspondingly, client will send its own certificate and the certificate
verify message to equipment to allow client authentication.
SEMI E132.1-0305 © SEMI 2005 11
Client
Equipment
ClientHello
ServerHello
Certificate
CertificateRequest
Certificate
ClientKeyExchange
CertificateVerify
ChangeCipherSpec
ServerHelloDone
Server public key certificate
Key Parameters:
session id
server random data
selected algorithms
Key Parameters:
protocol version
client random data
supported algorithms
Client public key certificate
session secret encrypted
with server's public Key
Client signature
ChangeCipherSpec
Finished
Finished
Sent under new algorithms
Sent under new algorithms
Session Request
Equipment Challenge
Client Authenticate
Equipment ACK
Figure 3
SSL Basic Handshake Flow
7.2 Credentials and Digital Certificates
7.2.1 Overview
7.2.1.1 X.509 certificates shall be used to establish identities for equipment and application clients. The certificate
is used by SSL for authentication and to establish secure connections between equipment and clients. An illustration
of the SEMI E132.1 security credentials showing role of certificates and ACL is presented in Figure 4. As shown,
an X.509 certificate binds an ID to a public key, managed by an agent called the CA described in following sections.
An ACL Entry binds the ID to a set of authorizations, managed by the Security Admin. Authorization management,
ACL Entry and Security Admin are as defined in SEMI E132, see Authorizations section.
SEMI E132.1-0305 © SEMI 2005 12
ID
Public/Private Key
Privileges
X.509 Certificate
E132 ACL Entry
E132 Principal Id = ID
Certificate Subject Name:
Common Name=ID
Security
Admin
CA
Admin Authority
Admin Authority
ID
Public/Private Key
Privileges
X.509 Certificate
E132 ACL Entry
E132 Principal Id = ID
Certificate Subject Name:
Common Name=ID
Security
Admin
CA
Admin Authority
Admin Authority
Figure 4
SEMI E132.1 Security Credentials
7.2.1.2 CA is the Certification Authority that issues certificates to equipment and application clients wishing to
communicate over SSL. The authenticity of the certificate is verified by the CA signature within the certificate, in
effect the CA is certifying the validity of the information contained in the certificate, more importantly it certifies
the binding between the entity identified in the certificate and its public key used for authentication purposes in SSL.
For more information on certificate validation and signature verification, please see referenced X.509 v3
documentation in ¶4.4. The CA may or may not be the same as the Security Admin as defined in SEMI E132,
which manages access control permissions for application clients. Implementation and maintenance of both the CA
and the Security Admin are the responsibility of the equipment user, including certificate issuance and security
credentials management. Equipment suppliers shall not be required to provide CA or Security Admin
implementations.
7.2.1.3 In this specification, only the common name (CN) attribute of the certificate’s subject distinguished name
(DN) is required, this is represented as ID in Figure 4. The same ID must be used by the Security Admin when
binding authorizations to a principal id in an ACLEntry. In summary, SEMI E132 principals are identified by the
common name (CN) attribute of the subject distinguished name field of the certificate issued to the principal.
7.2.1.4 Certificates issued by the CA for SEMI E132 shall be encoded in PKCS#12 format along with
corresponding private keys. Equipment shall support PKCS#12 to decode certificate and any associated private key
issued by the CA. There are no restrictions on the local encoding format of certificates. See PKCS#12
documentation referenced in ¶4.4 for complete details. The CA certificate will also be delivered in same format but
without the private key. The CA certificate is used by SSL for certificate verification.
7.2.1.5 Certificates must minimally support signing capability if the KeyUsage extension field is present in the
certificate, more specifically the digitalSignature bit must be asserted. Please see the X.509 v3 specification for
more information on certificate profile.
7.2.2 Establishing Equipment Credentials
7.2.2.1 Equipment must install both the CA’s public certificate and its own certificate along with the corresponding
private key, the CA certificate to verify client certificates are from the same trusted CA. Equipment is responsible
for decoding the PKCS#12 encoded certificates and private key from CA to a format supported by its
implementation.
7.2.2.2 An ACLEntry defining the Security Admin for the equipment must be added using the local equipment
interface. This shall be done at time of equipment install to allow remote administration of access permissions for
the equipment.
7.2.3 Establishing Application Credentials
7.2.3.1 Application clients wishing to establish SEMI E132 sessions with any equipment must first possess a valid
certificate issued by the CA prior to any communications. Equipment shall ensure SSL handshake terminates for
any client that does not present a valid certificate issued by a trusted CA. Similar to equipment certificates, all client
certificates and corresponding private key from CA will be encoded in PKCS#12 format. The CA certificate must
also be installed by the application client to verify equipment certificate chain.