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)

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.

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