RE: Request for new work item - Defining an SRV RR otherName

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

FYI

The SRV RR draft is now available from internet-drafts.

http://www.ietf.org/internet-drafts/draft-santesson-pkix-srvrr-00.txt


/Stefan
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Stefan Santesson
> Sent: den 20 maj 2005 22:07
> To: Sam Hartman
> Cc: ietf-pkix@xxxxxxx
> Subject: RE: Request for new work item - Defining an SRV RR otherName
> 
> 
> Sorry for being a bit unclear.
> Yes, you could use the Kerberos principal name specifically for
Kerberos
> but not for other service types.
> 
> The benefit from the proposed SRV RR other name is that you could
deploy
> a generic approach, which maps 1:1 to service lookup via DNS for a
wider
> range of services and avoid different solutions for each service type.
> 
> Yes, this means that we need to go through the pain to recognize a new
> otherName, but now when we have to go there, the thought is that we
then
> may be better served with a more generic approach for client side
> service validation rather than doing it just for Kerberos.
> 
> /Stefan
> 
> 
> 
> > -----Original Message-----
> > From: Sam Hartman [mailto:hartmans-ietf@xxxxxxx]
> > Sent: den 20 maj 2005 19:10
> > To: Stefan Santesson
> > Cc: ietf-pkix@xxxxxxx
> > Subject: Re: Request for new work item - Defining an SRV RR
otherName
> >
> > >>>>> "Stefan" == Stefan Santesson <stefans@xxxxxxxxxxxxx> writes:
> >
> >     Stefan> Sam, My recollection of this issue is a bit different
from
> >     Stefan> yours.
> >
> >     Stefan> The central need here is to enable the KDC to express in
a
> >     Stefan> certificate the fact that it is a KDC in a way that male
> >     Stefan> sense to clients.
> >
> >
> > If this is all you want, bind the KDC certificate to the TGS
principal
> > for the realm. That's what Larry's pkinit 26 text does.
> >
> > The original problem with that solution is that it required CAs to
> > implement the kerberos OtherName.  However this approach also
requires
> > the CA to implement a new OtherName.