Subject: Requested changes to SRV SAN

From: Stefan Santesson <[email-masked]>
Date: Wed, 21 Mar 2007 15:36:50 +0000

I want to check WG consensus for editorial actions or non actions as a result of discusses in the IESG process of the srv draft
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-04.txt

WE have 2 issues at hand:

1) Internationalization

The WG consensus of this draft was to store the srv name in UTF-8. The advantage is that this is the form the srv name will be entered and presented using CA admin tools and certificate viewers.
Concerns raised is that UTF-8 allows multiple encoding alternatives of identical strings. The document does require normalization prep operations but the chance of this not being done right is higher using UTF-8 compared with if the name is stored in ASCII punycode form in case an IDNA is used.

My position is that this is not a problem as long as comparison with DNS output is done in punycode form and I would rather keep the input and presentation encoding of UTF-8
However, I'm willing to accept storage as IA5 if this would be the WG consensus.

2) Request for an applicability statement

Sam Hartman has a discuss requiring this document to say that this name form MUST NOT be used unless explicitly allowed by the protocol being used.
Sam is in particular interested in making sure this name form is not allowed when authenticating a KDC.

I have severe objections against this requirement. Authentication based on a certificate can be done in any context, also outside the context of a transport protocol. It may be used when validating a signed statement following a signature format that is totally transparent and agnostic about what names the relying party chooses to accept.

If a specific security protocol needs to impose limitations of names being used to authenticate any involved entity, any such restrictions must be defined in that protocol and not by the document defining the name form. Specifically for Kerberos, Kerberos do already impose such rules but also allow authentication to be based on local policy. If local policy is used it is already understood that interoperability can't be expected outside of a local context. The srv san document has no business of dictating what that local policy might be.

I as editor do therefore not accept this change. I can however accept to state that use of this name form MUST be consistent with any protocol within which it is being used. This would however not satisfy Sam's discuss.

I ask the WG of your opinion on these issues.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Mar 2007 14:29:22 -0400

Stefan:

I want to respond to one part of your note.

>1) Internationalization
>
>The WG consensus of this draft was to store the srv name in UTF-8. 
>The advantage is that this is the form the srv name will be entered 
>and presented using CA admin tools and certificate viewers.
>Concerns raised is that UTF-8 allows multiple encoding alternatives 
>of identical strings. The document does require normalization prep 
>operations but the chance of this not being done right is higher 
>using UTF-8 compared with if the name is stored in ASCII punycode 
>form in case an IDNA is used.
>
>My position is that this is not a problem as long as comparison with 
>DNS output is done in punycode form and I would rather keep the 
>input and presentation encoding of UTF-8

I raised this question when the document was first posted.  I believe 
that storing punycode in the certificate subject alt name extension 
is the proper way forward.  I am concerned about comparison 
operations.  The string in the certificate needs to be compared to 
another string that is extracted from another protocol.  There will 
be fewer errors if the string from the protocol is converted to 
punycode and compared to the string in the certificate (that in my 
suggested way forward is already in punycode).

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 21 Mar 2007 16:18:20 -0800

> Sam Hartman has a discuss requiring this document to say that
> this name form MUST NOT be used unless explicitly allowed by
> the protocol being used.

Because . . . ?

Mike

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Mar 2007 14:38:10 -0400

I'm not sure I see this.
What's wrong with using UTF-8 and the IDNA procedures for comparing names for everything?

Why would you ever want to convert to punicode?

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Mar 2007 03:09:59 -0400

>What's wrong with using UTF-8 and the IDNA procedures for comparing 

I am concerned about the way that protocol fields will be defined in 
the future.  I fear that some of them will not include tagging to 
know whether the content is UTF8 or ASCII.  My understanding is that 
an attempt to convert an input using the IDNA ToASCII will result in 
the same value id the input is already ASCII, thus the output of 
ToASCII is the thing that ought to appear in the certificate extension.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Mar 2007 04:42:46 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Sam:
    >> I'm not sure I see this.  What's wrong with using UTF-8 and the
    >> IDNA procedures for comparing names for everything?

    Russ> I am concerned about the way that protocol fields will be
    Russ> defined in the future.  I fear that some of them will not
    Russ> include tagging to know whether the content is UTF8 or
    Russ> ASCII.  

Our character set policy requires thatprotocol fields have a well
defined character set.  So, we'll know if something can contain UTF8.
However you are correct that there is ambiguity about whether domain
names stored in UTF8 slots will be ascii or UTF-8.  It's worse in
cases where a UTF8 slot contains something that is sometimes a domain
name.

    Russ> My understanding is that an attempt to convert an
    Russ> input using the IDNA ToASCII will result in the same value
    Russ> id the input is already ASCII, thus the output of ToASCII is
    Russ> the thing that ought to appear in the certificate extension.

Converting to UTF8 is idempotent as well.  So you could stick the UTF8 string in the certificate extension and get the same affect.q

I don't see a way you can escape canonicalization to one format or
another on the verifying party.

    Russ> Russ

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Mar 2007 04:46:04 -0400

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    >> this name form MUST NOT be used unless explicitly allowed by

    Michael> Because . . . ?

Two reasons.  first, the SRV DNS RR definition has a very strong
applicability statement.  SRV records cannot be used except when a
protocol specifically defines their use.  This increases
interoperability.  You don't want some domains using MX to find mail
servers and others using _smtp._tcp.domain SRV records.  We should be
consistent with the SRV spec wehn definining name types for use with
those records.

Second, the underlying interoperability concerns for this name type
apply the are the same as for SRV records.  We've had enough trouble
with interoperability concerns caused by CN and email address in the
subject name vs subjectAltName choices.  We don't want to introduce
other situations where there are multiple ways of naming the same
entity without need to do so.

--Sam

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Mar 2007 12:07:06 +0000

I have already stated that I will go with the consensus here, but lets get the facts clear.

If you have the name in UTF-8 and perform a to-ascii conversion before comparison, then there is no problem.
Performing to-ascii is trivial once you have it implemented. To accommodate rfc3280bis section 7 for IDNA, you will need to implement to-ascii punycode anyway.

If the name is stored in UTF-8, all you ever will have to do is to-ascii.

If you store it in ascii form, you will also need to do to-unicode, every time you view the certificate content in a viewer. That is an extra burden.

However, both ways work, so this to me is a matter of taste.
In terms of implementation errors, I don't expect these proposals to make any difference. When certificates are parsed, naming values are mostly converted to a uniform internal encoding (unicode) anyway. At least in our environment as that makes APIs a lot easier.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 22 mars 2007 08:10
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: Requested changes to SRV SAN
>
>
> Sam:
>
> >I'm not sure I see this.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Mar 2007 11:51:54 +0000

Sam,

On your first reason

To compare with applicability statement for SRV DNS RR is really a bad example.

It is very natural and logical to have a very strong applicability statement for SRV DNS RR. It is used only in the context of DNS lookups. So naturally every service protocol MUST determine that such lookup is suitable AND register a service name for it to be applicable.

Defining a name form for a certificate is a very different thing. It is not used for any service lookup. It is used by the relying party locally to determine if it is authenticating an appropriate entity in virtually any situation. This is may not be tied to a specific situation or protocol.

When it is done in the context of a protocol, that protocol have to define any rules for applicable certificate content. Such as requirement for EKU, policy, name forms, key usages etc. It is that protocol definition that states the rules with functionality and interoperability in mind.

On your second reason;

Every protocol MUST define its own interoperability rules. Kerberos PKINIT has already done this. If this is not sufficient, then you need to update PKINIT and say that when the local policy option is used, all name forms are allowed except srvsan. Which to me would be kind of odd.

This would mean that the following text of PKINIT need to be updated:

   In addition, unless the client
   can otherwise verify that the public key used to verify the KDC's
   signature is bound to the KDC of the target realm, the KDC's X.509
   certificate MUST contain ......

To something like:

   In addition, unless the client can otherwise, through any means except
   reliance on any present srv subject alt name [ref], verify that the public
   key used to verify the KDC's signature is bound to the KDC of the
   target realm, the KDC's X.509 certificate MUST contain ......

But again, that would be kind of odd to say.

You simply can't police this by stating general rules for a name form for all protocols and validation situations. It would create a conflict in cases where a protocol or format is silent or partly open on certificate naming content, implying that it is up to the relying party to bind the names to a user in any way it can, according to local conventions. PKI is a framework that can be used for a wide range of protocols and applications. One size does not fit all.

Even though I can be sympatric to what you try to achieve, the way you propose to solve it does not work.
Frankly, I don't think we have any problem here. PKINIT is good as it is and already state the basis for interoperability.

Stefan Santesson
Senior Program Manager

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 22 mars 2007 09:46
> To: Michael Myers
> Cc: Stefan Santesson; [email-masked]; Stephen Kent; Tim Polk

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 22 Mar 2007 17:15:34 +0000

After listening to the Internationalization presentation in the IETF plenary session today, I do recognize the point to in general represent protocol elements in ascii when possible.

For those that were not present, the slides are available from:
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-3.pdf
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-4.pdf
http://www3.ietf.org/proceedings/07mar/slides/plenaryt-5.pdf

To take the charge of this issue, I do therefore propose that we simply represent srv names in ASCII (IA5String).
If nothing else, I feel convinced that it would make the approval process a lot easier.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 22 mars 2007 13:07
> To: Russ Housley; Sam Hartman
> Cc: [email-masked]
> Subject: RE: Requested changes to SRV SAN
>
>
> Performing to-ascii is trivial once you have it implemented. To
> accommodate rfc3280bis section 7 for IDNA, you will need to implement
> to-ascii punycode anyway.
>
> If you store it in ascii form, you will also need to do to-unicode,
> every time you view the certificate content in a viewer. That is an
> extra burden.
>
> In terms of implementation errors, I don't expect these proposals to
> make any difference. When certificates are parsed, naming values are
> mostly converted to a uniform internal encoding (unicode) anyway. At
> least in our environment as that makes APIs a lot easier.
>
>
>
> Stefan Santesson
> Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 23 Mar 2007 01:38:11 +0000

After some discussions face to face, it is clear to me that I have not been successful in explaining my point.

From what I have understood, Sam wants us to do is to say something like the following:
The srv subjectAltName name form MUST NOT be used to validate the identity of any entity unless the protocol within which the identification is done explicitly specifies and permits the use of this name form.

Sam has told me that it would not be sufficient to require the use of SRV SAN to be consistent with the protocol. It MUST be explicitly allowed.

The rest of this mail intends to explain why this is unreasonable and doesn't work.
I will first explain the general use case and then make an explicit example.

General use case

1) Client seek a service based on service name and domain.
2) Client makes a query to the DNS server and receives a list of suitable host names and their address.
3) The Client contact one of the hosts suggested by DNS
4) The client receive the certificate of that host
5) The client verifies the identity of the host and determine if this is a valid host for the requested service.

Note that the information from the certificate is NOT used to construct any DNS query. It is only used to validate the service host.
Note also that for this to happen at all, the service type asked for MUST be supported by the DNS or you would not reach beyond step 2. So for us to even consider the certificate in this case, we have an automatic guarantee that at least the DNS supports this service name as basis for host lookup. Thus it should already have passed the applicability statement of RFC 2782.

Lets now take a specific case.

1) Client seeks the LDAP server of example.com
2) Client makes a dns query for _ldap._tcp.example.com
3a) Client receives the following list of suitable hosts: ldap1.example.com and ldap2.example.com
3b) Client contact ldap://ldap1.example.com and initiates a TLS session according to RFC 4513
4) Client receives the server certificate from the TLS initialization.
5) Client verifies the server certificate according to RFC 4513.

Now. This server certificate has a subject DN with a number of attributes that does not mean anything to the client.
The server certificate contains the dnsName SAN with the value ldap1.example.com
The server certificate contains a SRV SAN otherName with the value _ldap.example.com

Through the dnsName SAN, the client will be assured that it is in fact talking to the host ldap1.example.com. But unless the client can fully trust the DNS, the client still don't know if this host is authorized to provide the ldap service for this domain. If the DNS was spoofed, the client could be talking to the wrong server.

But, here the CA has also bound the key to the srv name (_ldap.example.com). Through this name the client has an assertion from the CA that this host is actually an authorized ldap server for the example.com domain.

Must the client disregard from this information. YES according to Sam (If I understand him right).

Because RFC 4513 does not explicitly mention and approve use of the SRV SAN name form (And how could it, this name form is not an RFC yet)

RFC 4513 states:

3.1.3.  Server Identity Check

   In order to prevent man-in-the-middle attacks, the client MUST verify
   the server's identity (as presented in the server's Certificate
   message).  In this section, the client's understanding of the
   server's identity (typically the identity used to establish the
   transport connection) is called the "reference identity".

   The client determines the type (e.g., DNS name or IP address) of the
   reference identity and performs a comparison between the reference
   identity and each subjectAltName value of the corresponding type
   until a match is produced.  Once a match is produced, the server's
   identity has been verified, and the server identity check is
   complete.

This text is 100% consistent with using srv san otherName even though it is not explicitly mentioned.

So we have a case where use of DNS lookup for a service type that established and supported by DNS servers as well as having an IANA registered service name. We have a security protocol that provides freedom for clients to define what a "reference identity" is. Yet we would not be allowed to use the only name in the certificate that gives the client what it needs to verify the host.

That does not make any sense to me at all.

Why is it necessary to update RFC 4513 to make it legal to use this name form when its use is already consistent with the standard?
What if I have a privately defined SAN otherName, can I use that? I think RFC 4513 clearly allows that.
What if that privately defined otherName contains exactly the same info as our SRV SAN, can I use it?

Please clarify if I have understood you wrong Sam.

Stefan Santesson
Senior Program Manager

---

From: Scott Lawrence <[email-masked]>
Date: Sat, 24 Mar 2007 09:42:23 +0100

> defined character set.  So, we'll know if something can contain UTF8.

But UTF-8 is not a character set, it's an encoding that can be applied
to any Unicode character set.

I think that the principle elucidated in the plenary applies - on the
wire one should use the punycode form, and only translate in the UI.
For the purposes of this decision, I think that both certificate
contents and DNS records are 'on the wire'.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/