I don't want to go down the path of arguing these cases, particularly if they've been hashed out thoroly before, but the better we understand how people expect to use proxy certs, the better the OCSP scenarios will be. I am going to rearrange the order of the comments. "Olle Mulmo" writes:
[B] But all we can do is stamp the public key, not the private key. We can't tell if a private key has migrated somewhere we don't want it to be.
Arguably, you don't really care about the location: you care about the protection. Key server A may securely transfer it to key server B for redundancy purposes, a key on a smart card moves around as the user moves around, and so on.
Ok, I don't care about the smart card case in this context; I assume that proxy certs are never on such a device. But is that true? 2nd, one of the justifications I heard years ago for proxies was to cross administrative domains ie delegate a right from userA on host alpha to userA (same) on host beta. Clearly "key pairs COULD be copied but shouldn't be" was one of the guiding principles. But is that true? Are there scenarios where people expect & need to be able to pack up & move their proxy private keys? Let me assume the answer is either a) they don't or b) these are very specific well - defined cases. If neither, then I don't think what follows is useful anyway.
A) What if proxy certs had a "Made at <X>" stamp on them (Does anybody do this now?) Would this help?
This has been discussed before, and that kind of stamp would be useless unless it came from someone trusted party (i.e., not the user) that "vets" the key pair: it's associated owner, it's location (maybe), it's level of protection, and so on.
Having such a beast around would allow us to shortcircuit and circumvent a lot of the problems, so rather than using it as a patch to the patch to the original problem, it would allow for completely new usage scenarios.
I am not sure why you need that level of assurance about the "made at <X>" assertion (sure it couldn't hurt). Let's use Matt Crawford's diagram: "When a user on host A delegates to B, which then authenticates to C, the proxy cert is created at A, stored at B and seen at C." The made-at assertions seem like any other that might be in a proxy cert, but I am assuming the user at A is making this assertion along with the rest of his ID info. If he puts the wrong made-at information in the cert, the worst that can happen is that he denies himself some service by failing some policy test - either on B or C. But the difficulty I see with this is that we really want to stamp the proxy private key with this made-at info, the proxy certs themselves are used to cross admin boundaries. There is no standardized private key usage management (people have talked about things like that and I think Entrust has some features but nothing general that I know of). Thanks, ==mwh