We are working on incorporating the attestation feature into the TLS handshake (as a TLS extension). It provides an additional layer of authentication (remote software stack authentication in addition to certificate-based user authentication) that can be useful for different purposes. Some past work, for example, involves integrating attestation in remote access to enterprise networks - where system administrators want to ensure that employees' laptops, which were compromised while being used in a coffee shop for example, cannot bypass security policies by connecting to the network later from within the firewall security parameter.
I am not sure what you meant about a certificate not being able to have a nickname if it has a NULL subject field. I can import such a certificate with the command "certutil -A -n <nickname> ..." and then access that certificate from a sample NSS application using FindCertByNickname with the default NSS database (my application really has only one NSS database). Should this work differently in FF?
As a side note, the attestation identity certificates are not used to authenticate users, actually they maintain the privacy of the user. An AIK certificate asserts that the public key contained in the certificate is associated with a trusted TPM platform. When a CA signs this certificates, it will ask you for a certificate from the manufacturer of you machine saying that the machine contains a TPM hwardware component that obeys the Trusted Computing Group specifications. Having this assurance, the CA signs your AIK certificate, certifying that this public key is associated to a trusted TPM. You would send that certificate together with an attestation response and the remote side will use the AIK public key to verify the signature of the PCR values (which the TPM signed with the private key corresponding to your attestation identity). So, I believe that the subject field of the AIK certificate must be empty (by specification) due to privacy reasons - otherwise it could contain information that reveals the identity of the user...
So, there are two issues I see about incorporating the TPM functionality in NSS:
- making the TPM available in a PKCS#11 slot: First, the private key never leaves the TPM. Also, how would the attestation and sealing functionality be exposed through the slot function list? These are two pretty unique cryptographic functions, they involves the PCR registers (or a subset of them) which are already in the TPM.
- the issue of the NULL subject of the AIK certificate - how to preserve compliance with the TCG standard which specifies these NULL values?
Any opinions are welcome :)
Regards,
Peter
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
