Creating HMAC keys using a fixed prefix and a random string In a system that uses HMAC for a number of different applications, it is important to use different keys for different applications.  Suppose:


there is just a single random string available (50 bytes long, in this case) 
we are using HMAC-SHA1 
we will shorten keys longer than the blocksize using SHA1 (as per RFC 2104)


Is it safe to generate unique keys by prefixing the application name to the secret, so that the key for application 1 ends up as SHA1("application1" + secret) and the key for application 2 ends up as SHA1("application2" + secret)? The strings "application1" and "application2" are not kept secret. Or does this open up significant weaknesses compared to using completely different secret keys for each application?

Thanks.
Let's put it more formally first. Let $s$, $t$ be strings known to the adversary, and $k$ be a secret key. Let $k_1$ and $k_2$ be the keys obtained as $k_1 = H(s|k)$ and $k_2 = H(t|k)$ respectively, where $H(\cdot)$ is a collision-resistant hash function, and $|$ denotes the concatenation. The question is, 


  Is function $f_i(\cdot)=HMAC(\cdot, k_i)$ a MAC?


The answer is yes. I don't have a formal proof, yet the following reasoning seems just fine (see also this topic): 
Given $s$ and $t$, and keeping $k$ secret, the adversary will be unable to deduce $k_1$ or $k_2$ with non-negligible probability. Lacking access to $k_i$, the key to HMAC, function $f_i$ will indeed act as a MAC.