A certificate establishes a link between an identity and a public key; the link is "guaranteed" by a Certification Authority with some sort of digital signature or another similar cryptographic binding.
The Wikipedia page on "implicit certificates" (pointed to by @Clayton) describes a concept where the public key algorithm is such that the public key, the key owner name, and the signature from the CA are somehow conflated into a single lightweight element. This concept seems to have emerged from the ECQV algorithm, and "implicit certificate" was coined as a sales pitch for that algorithm. Indeed, you can find the (slightly marketing toned) description from Certicom. It seems to be (possibly) subject to a host of patents (e.g. this one).
Though the concept is generic, I am aware of only one actual implementation, which is ECQV. It is not standardized and deployed yet.
In ECQV, the mechanics of the algorithm contrive to store into a single element both the public key and the sort-of-signature from the CA, while the element is no larger than the public key alone. A system trying to use the implicit certificate for a given user needs three elements:
- the purported key owner identity;
- the implicit certificate for that owner;
- the CA public key;
and the ECQV algorithm takes all three elements to output the user's public key. This is implicit in that it is not known yet whether the certificate really exist; i.e. given an implicit certificate C and the CA public key P, the ECQV algorithm says: if the certificate C is owned by user U, then the public key of U is K. All the "implicit" resides in the "if".
A roughly similar concept, but more extreme, is identity-based cryptography. In ID-based crypto, more mathematics are thrown at the problem (pairings on elliptic curves...) so as to achieve an even better result: removal of the certificate. The certificate is so implicit that it no longer needs to exist at all. With ID-based cryptography, the user's identity is his public key. ID-based crypto is "better" than implicit certificates because it allows public key usage out of the blue. Consider for instance the problem of sending an encrypted email to somebody (let's call him Bob):
- With classical (say "explicit") certificates, you have to first get Bob's certificate. E.g. Bob sends it to you (traditionally with a signed email) or your software finds it in some directory.
- With implicit certificates, you still have to get Bob's certificate. It is shorter, thus "more efficient", but you need it.
- With ID-based crypto, you don't need Bob's certificate. You already have it: it is Bob's name, i.e. "Bob". This is sufficient for you to encrypt and send the email.
It seems to me that the implicit certificate concept, i.e. ECQV, has trouble finding some market share; it is squeezed between "normal" certificates, over which ECQV only offers some perceived performance advantage (which, more often that not, has no relevance whatsoever), and ID-based cryptography, which offers some really structural advantages.
(It has been reported that Certicom and other patent owners still succeed in pushing their algorithms in some standardization committees through intense lobbying. I have not witnessed such things myself, though.)