This is sometimes called a hierarchical signature scheme or a blinded signature scheme. Examples of the idea are being considered or adopted in Tor for next-generation onion services, in Bitcoin BIP32 for cheap many-address single-private-key wallets, and possibly by the IETF for standardization. There was a good summary discussion with references on the CFRG mailing list a few months ago. But the idea is not currently standardized, and implementations aren't littering the roads like implementations of ordinary signature schemes are.
$\newcommand{\Z}{\mathbb{Z}}$The basic idea of an elliptic-curve signature scheme using an order-$\ell$ group of $k$-rational points of an elliptic curve $E$ is that a private key is a secret scalar $a \in \Z/\ell\Z$, a public key is the curve point $A = [a]P$ where $P$ is a standard $k$-rational order-$\ell$ base point, and a signature is some point and scalar that satisfies some verification equation involving $A$.
Typical examples in this design space are ECDSA, for an archaic slow error-prone one, and EdDSA, for a modern fast safe one. They can both be adapted to hierarchical/blinded schemes.
The basic idea of an elliptic-curve hierarchical/blinded signature scheme is to ‘tweak’ the public key and private key in the same way by another scalar $t \in \Z/\ell\Z$. The derived private key is the scalar $a_t \equiv t a \pmod \ell$, and the derived public key is the curve point $A_t = [t]A = [t a]P = [a_t]P$. The signature verification equation is the same as in the underlying signature scheme. Anyone who knows the tweak and the original public key can verify signatures using the derived public key; anyone who doesn't know the tweak can't tell a derived public key from any other curve point.
A devil lurks in the details like Sean Spicer in the bushes: you may need to pay attention to cofactors, malleability of signatures and public keys, etc.—that's why some people want the IETF to standardize a hierarchical signature scheme for the internet, so that individual application developers need not learn the hard way about covfefe or other similar pitfalls of novel developments in public-key cryptography.