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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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.