[caops-wg] OCSP & Proxy Certs

[Mike Helm]

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