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

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 26 Sep 2005 01:15:43 +0100

Tom,

I share your concern regarding processing name constraints on an OCTET
STRING encoded name form. And I do believe that name constraining might
be very useful for this name and as such this draft should define name
constraints matching rules for it.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 25 september 2005 17:09
> To: Stefan Santesson; [email-masked]
> Cc: Russ Housley; [email-masked]; Paul Hoffman
> Subject: RE: draft-ietf-pkix-srvsan-00
> 
>         Kurt:
> 
>         Stefan's point about name constraints argues relatively
strongly
> in favor of a string-based matching rule, which suggests a string
> encoding.  In particular, the existing URI or DNS name constraint
rules
> could appropriately be applied to this OTHER-NAME form - if a CA may
only
> certify URI's within a given set of domains, I can't see why it should
be
> allowed to certify a user with this name form outside those domains.
> Either of those matches are obviously character string matches, and
they
> don't make sense as pure binary ones given the distinction between
periods
> and all other characters - although you could implement a pure binary
> trailing substring match if the constraint string started with a
period.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Kurt D. Zeilenga" <[email-masked]>
> Sent by: [email-masked]
> 09/24/2005 11:18 AM
> 
>         To:     Russ Housley <[email-masked]>
>         cc:     "Stefan Santesson" <[email-masked]>, Paul
Hoffman
> <[email-masked]>, [email-masked]
>         Subject:        RE: draft-ietf-pkix-srvsan-00
> 
> 
> 
> My point is that each DNS name is a sequence of DNS
> labels, each label being an octet string.
> 
> Kurt
> 
> At 11:15 AM 9/23/2005, Russ Housley wrote:
> 
> >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
> 
>