[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)
On 20 Oct 2009, at 21:44, Scott Cantor wrote: > 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. RFC 4120 section 6 is concerned with "naming constraints" and "what information [names] imply". I believe that the constraints imposed by this section satisfy the "self-describing" property, but I would welcome your opinion. For example (section 6.1, concerning realm names): > The following additional constraints apply to the assignment of > realm names in the domain and X.500 categories: either the name of a > realm for the domain or X.500 formats must be used by the > organization owning (to whom it was assigned) an Internet domain > name or X.500 name, or, in the case that no such names are > registered, authority to use a realm name MAY be derived from the > authority of the parent realm. >> 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. Ok, I'm happy to do something different if that makes life simpler. > Perhaps it's enough to create separate conformance profiles for > public-key > mechanisms and this. That works for me. Many thanks, josh.