[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]