Subject: RE: draft-ietf-pkix-srvsan-00

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 23 Sep 2005 23:36:48 +0100

Agree with Russ. The correct way is to include multiple instances of the
same otherName. Eventual name constraints definitions would be awful if
the name form would be defined as a sequence.

Talking about that we might just as well define the name constraints
matching rule for this name form. It would be rather easy. Taking the
dNSName rules from RFC 3280bis and add the service parameter to the
rules.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 23 september 2005 20:15
> To: Kurt D. Zeilenga
> Cc: Stefan Santesson; Paul Hoffman; [email-masked]
> Subject: RE: draft-ietf-pkix-srvsan-00
> 
> Kurt:
> 
> Yes, if you want to allow the other name to represent more than one
SRV
> record.  No, if you want to include a separate other name instance for
> each
> SRV record, which is more consistent with the way that tow URLs would
be
> represented.
> 
> Russ
> 
> At 02:00 PM 9/23/2005, Kurt D. Zeilenga wrote:
> >At 09:24 AM 9/23/2005, Paul Hoffman wrote:
> > >>Therefore, it seems to me that the OCTET STRING is the form that
> > matches the sequence of octets that will actually be provided by a
DNS
> > query.  Then, the ToUnicode routine is used to convert for display
to a
> human.
> > >
> > >Russ is completely correct: don't convert if you don't have to, DNS
is
> a
> > binary transport, so OCTET STRING is the correct way to not lose
data.
> >
> >wouldn't SEQUENCE OF OCTET STRING be more appropriate?
> >
> >Kurt