Environments:

• Staging: test your deployment process/scripting (not your code)
  • no developers access, unless they are also sysadmins
  • very restricted outbound networking
  • mirrors production as best as possible
• Pre-production (optional): test the code in prod env wo/impacting customers
  • test app w/prod setting wo/customer interaction
• Production: real live environment
  • developers not have access (they can be tempted to fix something)
  • deployment should be done wo/developer input
  • very limited inbound traffic, generally only the service that being served

Deployment options:

• rsync
• source control
• PEAR
• os-based

Which should you use?

• something simple: rsync
• multiple dispare platforms: pear
• internal w/minimal dev input: os-based (like. yum/apt)

References:

• phing + rpm
  • process automatization with phing
    • pack sources in a .tar.gz file
    • creat .rpm package
    • deploy package to a .rpm repository
• PHP deployment using rpm

• Public-key cryptography is a cryptographic approach which involves the use of asymmetric key algorithms instead of or in addition to symmetric key algorithms.

• Asymmetric key algorithms are used to create a mathematically related key pair: a secret private key and a published public key.

• public key fingerprint: is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic hash function to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks.

Public-key cryptography, how it works: Wikipedia

• Authenticity: we can create a digital signature of a message with private key and it can be validated with public key.
• Confidentiality and Integrity: encrypt message using public key, only can be uncrypted with private key.

• Creating pub and private key: An unpredictable (typically a large randomly chosen) number is used to begin generation of an acceptable pair of keys suitable for use by an asymmetric key algorithm.

• Example of encryption:In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. Security depends on the secrecy of that private key.

• Example of signature: In some related signature schemes, the private key is used to sign a message; but anyone can check the signature using the public key. Validity depends on private key security.

• Diffie-Hellman fundamentals:In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key. After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used as the key for a symmetric cipher.

My own schemas:

• encrypt a document: send a document encrypted using your private key but it can be decrypted with your public key, this is a guarantee for athenthicity, only you can do a document that can be decrypted with your public key
  

• sign package: with private key can sign a package, then when anybody has package using the public key can verify that is a trust package

• sign raw data: the process and result is the same, when sign a package

• secure mail:
  • for sign and crypt a raw email, the procedure is create a hash signature of raw data, then signature is encrypted with private key finally raw data + signature are encrypted with public key of the recipient.
  • when recipient recieves secure mail, using private key decrypts de package and gets raw email + mail signature. Now recipient can read email but after decrypting signature with public key of sender obtains mail hash signature after validating the signature recipient knows authenticity of mail.

• ssl_basics and diffie hellman: using priv key #1 and pub key #2 can get a key, and using priv key #2 and pub key #1 can get the same key. This shared key is not exchanged over the network and only user #1 and #2 can get it, then they use the key for a symetric cypher mechanism because it needs less resources than use pub-key mechanisms to encrypt packets. Cypher mechanisms used by SSL typecaly are: AES, DES, 3DES, Blowfish, RC4, etc.

• PKI:
• PGP uses web of trust instead of PKI
• SSL v2 and v3. The Secure Sockets Layer (SSL) protocol allows mutual authentication between a client and server and the establishment of an authenticated and encrypted connection.
• TLS v1 (RFC 2246). The Transport Layer Security (TLS) protocol from the IETF will eventually supersede SSL while remaining backward-compatible with SSL implementations.
• PKCS #1. RSA standard that governs implementation of public-key cryptography based on the RSA algorithm.
• PKCS #3. RSA standard that governs implementation of Diffie-Hellman key agreement.
• PKCS #5. RSA standard that governs password-based cryptography, for example to encrypt private keys for storage.
• PKCS #7. RSA standard that governs the application of cryptography to data, for example digital signatures and digital envelopes.
• PKCS #8. RSA standard that governs the storage and encryption of private keys.
• PKCS #9. RSA standard that governs selected attribute types, including those used with PKCS #7, PKCS #8, and PKCS #10.
• PKCS #10. RSA standard that governs the syntax for certificate requests.
• PKCS #11. RSA standard that governs communication with cryptographic tokens (such as hardware accelerators and smart cards) and permits application independence from specific algorithms and implementations.
• PKCS #12. RSA standard that governs the format used to store or transport private keys, certificates, and other secret material.
• S/MIME (RFC 2311 and RFC 2633). IETF message specification (based on the popular Internet MIME standard) that provides a consistent way to send and receive signed and encrypted MIME data.
• X.509 v3. ITU standard that governs the format of certificates used for authentication in public-key cryptography.
• OCSP (RFC 2560). The Online Certificate Status Protocol (OCSP) governs real-time confirmation of certificate validity.
• PKIX Certificate and CRL Profile (RFC 3280). The first part of the four-part standard under development by the Public-Key Infrastructure (X.509) working group of the IETF (known at PKIX) for a public-key infrastructure for the Internet.
• RSA, DSA, ECDSA, Diffie-Hellman, EC Diffie-Hellman, AES, Triple DES, DES, RC2, RC4, SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD5, HMAC: Common cryptographic algorithms used in public-key and symmetric-key cryptography.
• FIPS 186-2 pseudorandom number generator.
• SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) – is a GSSAPI “pseudo mechanism” that is used to negotiate one of a number of possible real mechanisms.
  • SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports.
  • The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.
  • SPNEGO's most visible use is in Microsoft's “HTTP Negotiate” authentication extension. It was first implemented in Internet Explorer 5.01 and IIS 5.0 and provided single sign-on capability later marketed as Integrated Windows Authentication. The negotiable sub-mechanisms included NTLM and Kerberos, both used in Active Directory.
  • RFC 4178
• SASL (Simple Authentication and Security Layer) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL.
  • Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another.
  • They can also provide a data security layer offering data integrity and data confidentiality services.
  • DIGEST-MD5 provides an example of mechanisms which can provide a data-security layer.
  • Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.
  • SASL mechanisms
    • “EXTERNAL”, where authentication is implicit in the context (e.g., for protocols already using IPsec or TLS)
    • “ANONYMOUS”, for unauthenticated guest access
    • “PLAIN”, a simple cleartext password mechanism. PLAIN obsoleted the LOGIN mechanism.
    • “OTP”, a one-time password mechanism. OTP obsoleted the SKEY Mechanism.
    • “SKEY”, an S/KEY mechanism.
    • “CRAM-MD5”, a simple challenge-response scheme based on HMAC-MD5.
    • “DIGEST-MD5”, HTTP Digest compatible challenge-response scheme based upon MD5. DIGEST-MD5 offers a data security layer.
    • “NTLM”, an NT LAN Manager authentication mechanism
    • “GSSAPI”, for Kerberos V5 authentication via the GSSAPI. GSSAPI offers a data-security layer.
    • GateKeeper (& GateKeeperPassport), a challenge-response mechanism developed by Microsoft for MSN Chat
• PAM (Pluggable Authentication Modules) – can use kerberos but not support SSO
• SSH uses PAM, if we want to use SSO with kerberos needs a GSSAPI patch
• SSSD (System Security Services Daemon ) – It's primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system.
  • NSS interface
  • PAM interface
  • Offline credentials
  • DBUS service called InfoPIPE
• DSML Gateway – http://directory.fedoraproject.org/wiki/DSML_Gateway_Design
• x509 – http://en.wikipedia.org/wiki/X.509
• RADIUS = AAAA (Autenticación, Autorización, Accounting y Auditing)
  • FreeRadius – http://freeradius.org

Software and libraries for pub-key infraestructure:

• NSS – Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. For detailed information on standards supported, see Overview of NSS.
• GSSAPI or GSS-API (Generic Security Services Application) – applications programming interface for programs to access security services. IETF standard.
  • The definitive feature of GSSAPI applications is the exchange of opaque messages (tokens) that hide the implementation detail from the higher level application.
  • The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations.
  • GSSAPI tokens can usually be sent over an insecure network as the mechanisms provide inherent message security. After some number of tokens have been exchanged, the GSSAPI implementations at both ends inform their local application that a security context has been established.
  • Typical protections guaranteed by GSSAPI are confidentiality and integrity. It's important to mention that authorization is not offered by GSSAPI.
  • In the API there about 45 procedure calls.
  • The GSSAPI allows Kerberos implementations to be API compatible.
  • GSSAPI support SPENGO it's a pseudo mechanism to negotiate new security mechanisms.
  • Known mechanisms: Kerberos, NTLM, DCE, SESAME, SPKM, LIPKEY.
• SSSD – https://fedorahosted.org/sssd/
• GOSA – https://oss.gonicus.de/labs/gosa/
• WebAuth: Kerberos a Apache – http://webauth.stanford.edu/

Wikipedia is the most important font of this gloassary. Thanks to everyone who makes it possible.