Re: Key Discovery

Thank you for your feedback, Anders.

During the Working Group face to face, it was agreed to keep the
knowledge of X.509 specific structures, such as logotypes, to a
minimum. Further, since the API is trying to avoid mandating any
specific user interactions, it is likely that any handling of
logotypes in relation to user interaction will be something that will
be implementation/user-agent defined and not part of the core
specification. Thus, it is unlikely that your requirements for SKS
will be mandated within the spec.

That said, the possibility for application-defined metadata to be
associated with keys is one proposal that was floated during the
recent face to face, so as an application developer, you should be
able to associate X.509 meta-data with keys and handle them at the
application layer.

I suspect your remaining issues may be addressed by the next revision
of the Editor's Draft, which will describe the representation of keys
and queries. The discussions from the face to face should have
resolved many of the outstanding questions.


On Sat, Jul 28, 2012 at 11:52 AM, Anders Rundgren
<> wrote:
> I'm trying to follow the discussions but I find myself lost here.
> This is my take on the subject:
> Domain-bound keys
> ---------------------------
> For domain-bound keys the scope is restricted to the keys that the Issuer/RP created.
> An opaque domain-local KeyID should be sufficient.
> Domain-bound keys should (at least in my mind) be constrained to a specific client-defined container.
> The need for UI selection seems limited.  If the Issuer/RP can's keep track on its own operations it would be wrong to let the user take this burden.
> Non-bound keys
> ---------------------
> Non-bound keys need a combination of UI selection and filter parameters.
> For UI-selections you also need key pinning.
> Key look-up API functions are likely to create privacy issues.
> Algorithm filtering
> -------------------------
> If you have no idea what the keys the client has you have a problem.
> Algorithm filtering doesn't seem to be the right "cure".
> SKS additions for non-bound keys
> ----------------------------------------------
> All keys must have an X.509 certificate as ID regardless if it is a PKI key or not.
> Keys should be fitted with logotypes to make UI selections easier.
> Anders

Received on Sunday, 29 July 2012 01:53:12 UTC