RE: [security-services] suggested HoK URIs and namespace prefixes

["Scott Cantor" <cantor.2@osu.edu>]

> Yes, I reread that exchange and I think you're right.  For the record,
> I was talking about the time of proof of possession *to the issuer*.

Right.

> In the same way that AuthnInstant reflects the time of authentication,
> ProofInstant reflects the time of proof of possession.

Right, but since it's strongly related to authentication, I think
AuthnContext is probably where it belongs. And I think the same sort of
people that convince themselves to care about this obscure detail are the
same sort who care about all the other obscure things that AuthnContext
represents.
 
> If there were no SSO, AuthnInstant would be unnecessary.  Likewise if
proof of
> possession is ALWAYS freshly established for each request to the
> issuer, there is no need for ProofInstant.

I don't think there's a strong need. You trust the IdP or you don't. These
kinds of policy distintions are among what holds back PKI. But I'm just
recognizing/agreeing the datum you're describing is something that isn't
represented at the moment.

My general feeling here is that unless somebody is prepared to argue that
HoK is somehow not being used because of this omission, it's probably not
worth worrying about. I wouldn't go inviting the sort of complexity that
colors the LOA discussions.

> Well, if we assume that the presenter always proves possession at the
> issuer, there's nothing to worry about.  By the way, the use cases I
> have in mind satisfy that requirement.  If there are other use cases
> that don't, then we have yet to determine if they can be rolled into
> this profile.

I think it's overly broad to take on authentication of requests in this
profile, and that's what you have to do if you want to require that.

I can easily imagine requiring particular authentication methods or
strengths in a deployment, but not in a profile that isn't even about a
single protocol.

> Can you provide a pointer, please?

https://spaces.internet2.edu/display/SHIB/MetaSearch

> How and when does proof of possession take place?

Servers normally use TLS or signatures, so it's proved over and over again
as you'd expect. I expect that to be typical, and I'm not arguing otherwise.
I'm just saying there are obvious (to me) ways to do authentication that
wouldn't work that way, and I don't think it's necessary to rule them out.
It would certainly be a first for us to do so.

> Sorry, I don't see it that way.  In my mind, there are two
> requirements that can not be relaxed:
> 
> 1. The presenter MUST present an X.509 public key certificate
> 2. The presenter MUST prove possession of the corresponding private key

I think I proved both to be orthogonal.

> The first requirement justifies the choice of ds:X509Data as a child
> element of ds:KeyInfo.

Again, knowing a certificate ahead of time is just as strong a
justification.

> The second requirement justifies the binding
> of the X.509 data to the assertion in the first place.  Without the
> latter, it seems a timestamp is required, as argued above.

Required by whom? Not by me, that's for sure. It's informational.
 
> Frankly, I don't know how to write a profile without these two
> requirements.  If someone else wants to give it a go, please do.

You take it all out and say nothing about how/why the assertion was issued
in the first place, because it's out of scope.

> You'll have to find someone else to engage in this religious battle
> :-)

The religious view is claiming that I'm wrong. Mine is the pragmatic view,
based on what's actually necessary to achieve the result.

> My immediate goal is to profile HoK subject confirmation in as
> broad fashion as possible.  Since keys are almost always bound to
> certificates in flows, the above requirements seem to make sense.

I think it's more narrow, not more broad. Requiring certificate matching
just doesn't serve any purpose. If the key's the same, it's the same. If you
need to rely on the certificate itself, then as I said, you didn't need
SAML.
 
-- Scott