OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Proposed Agenda SSTC Conference Call (October 20, 2009)


Josh Howlett wrote on 2009-10-20:
> My preferred approach is to modify the Metadata IOP so that it
> considers the case where Kerberos data (specifically, an element
> naming a Kerberos principal) is available within the <KeyDescriptor>.
> In this way, its use is analogous to <KeyName>.

It may be analagous, but the major issue with KeyName is that its use
doesn't tell anybody what to do precisely enough. That's the point of this
profile, to avoid anything that has shades of gray at runtime.

Is it the case that identifying a Kerberos principal is suitably
self-defining? I think it's somewhere in the middle, but probably good
enough. Strictly speaking, you're identifying a principal and a realm, but
there's no way to guarantee that my definition of realm X is the same as
yours.

But anybody using Kerberos is pretty likely to have that addressed OOB,
which is what distinguishes it from PKI, in which there is a dependence on a
non-existent directory (X.500) to address interoperability of naming and
locating trust anchors.

> Does this seem a reasonable approach?

I'm not strictly against it, but it would need to be an optional item for
conformance (or a separate conformance class), because I can't get adoption
if people are required to implement support for Kerberos-based trust in
order to conform to this profile.

Perhaps it's enough to create separate conformance profiles for public-key
mechanisms and this.

-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]