Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 03 Dec 2010 16:37:47 -0700

Hi Ben, thanks for the review.

[ + [email-masked] ]

On 12/3/10 2:24 PM, "Ben Campbell" <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-saintandre-tls-server-id-check-11
> Reviewer: Ben Campbell
> Review Date: 2010-12-03
> IETF LC End Date: 2010-12-16
> 
> Summary: This draft is almost ready for publication as a BCP. I have a few
> questions and comments that I think should be considered first, as well as a
> few editorial comments.
> 
> *** Major issues:
> 
> -- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to
> see more discussion around URI-IDs. These seem to me to be the most complex ID
> type to get right, but there are no examples and limited discussion. Picking
> on SIP, purely as an example for which I have a passing familiarity: Would a
> SIP reference identity match a SIPS URI-ID in a certificate? Do I put both a
> URI-ID and an SRV-ID in my reference set and/or certificate?  How do I handle
> the fact that I sometimes need to do a NAPTR query, before the SRV query
> depending on whether I know the transport protocol? (I realize SIP already
> defines cert ID matching, but what would I do for a new application protocol
> URI with similar properties?)
> 
> I wonder if the answer is that such things are scheme specific, and that its
> hard to say much about the generic handling of URI-IDs. If so, it might be
> worth mentioning that, and maybe discuss what things the designer of a new
> scheme should keep in mind.

I agree that we need to say more about URI-IDs. I also agree that the
recommendations are probably more technology-specific than for other
identifier types. Jeff and I will work on some text and reply further.

BTW, are you aware of any technologies other than SIP that use URI-IDs?
That's the only one I'm aware of.

> *** Minor issues:
> 
> -- 1.2, last paragraph:
> 
> Nothing normative here? Do we think that protocol designers SHOULD reference
> document instead of rolling their own? For example, would you expect
> additional IESG or SECDIR scrutiny for a new spec that rolls its own rather
> than referenda this? As stated, this paragraph makes it sound like this is
> something designers could use, rather than something designers should use. It
> seems like a BCP might take a stronger position.

If two poor suckers go to the trouble of working up a BCP, I'd hope that
folks would reference it when developing future protocols. But I don't think
putting a few MUSTs and SHOULDs in Section 1.2 is the way to make that
happen.

> -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from
> Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related
> technologies such as [S-NAPTR], since such identifiers cannot be validated in
> a trusted manner in the absence of [DNSSEC]."
> 
> Does that mean validation of a source domain that will be used to construct a
> NAPTR request is out of scope, or just validation against the result of a
> NAPTR query? (I note SIP may require the first).

Another good question. Jeff and I need to research this a bit more before
replying definitively.

> -- 2.3, paragraph 1:
> 
> A DN example might be helpful.

Never enough examples. :) We'll see about adding one here.

> -- 2.3, paragraph 3: "application service is identified by a name or names
> carried in the subject field and/or in one of the following identifier types"
> 
> May be identified, right? Since, as you mentioned earlier, it is common to
> identify a service with a name plus service designator, and only the SRV-ID
> and URI-ID intrinsically do this.

Fixed.

> -- 3.1, rule 3:
> 
> What happens when you have multiple schemes that are defined to refer to the
> same  resource. For example, SIP and SIPS? Does a SIP URI-ID match an
> otherwise identical SIPS URI-ID? (Maybe this should be left to the URI
> definitions themselves, but it might be worth mentioning the complication
> somewhere.)

Given that a user agent would not connect to sip:example.com or
http://example.com/ via SSL/TLS, it seems appropriate for the certificate to
include only the TLS-aware scheme (sips:, https:, etc.).

> -- 3.1, rule 5: "... unless a profile of this specification... "
> 
> This pattern recurs throughout the document. Can you elaborate on what you
> mean by "profile"? Normally I think of a "profile" as defining a subset of
> choices for some particular application. But if a profile relaxes a
> requirement (i.e. encouraging something that is a SHOULD NOT here), that's not
> really a subset.  Are you referring to an application protocol spec that
> refers to this document? Updates to this document? (I'm not sure if this
> should count as a minor issue or an editorial comment. It depends on whether
> its just a confusion around the word choice, or whether you have something
> specific in mind that I did not grok).

I think it's a terminological issue. By "profile" we mean "a specification
that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses this I-D.
The relationship is not one of defining a subset, but of being a downstream
customer. Is there a good, single word for that? If not, I think we can say
"Specifications that re-use this one" (ugly, but descriptive).

> -- 3.1, rule 6:
> 
> Can you motivate why this is not a MUST NOT?

Jeff has better numbers on this than I do, but a non-trivial number of
existing certificates contain multiple CN-IDs. In addition, as long as
control over the domain names has been certified then folks on the CertID
list and other reviewers did not see harm in allowing CAs to include those
domain names in CN-ID form, although it's not encouraged to do that.

> -- section 3.2:
> 
> I'd like to see a (non-trivial) URL-ID example.

Yes, we'll work to add that.

> -- 3.2, first example:
> 
> Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in
> examples? The example does seem to make sense, but it makes me wonder if the
> SHOULD NOT would be better placed on the client verification process not the
> cert generation process.

I think it's better to delete that instance from the first example.

> --4.2.1, paragraph 3:
> 
> It's probably out of scope, but it might be useful to offer some guidance on
> how ensuring the extraction is "not subject to subversion" is not always
> trivial. For example, if you got your input URI by clicking on a link in a
> phishing email, that can be almost isomorphic to using a delegation from a
> non-trusted source.

This is a matter of extracting the source domain from the input. Naturally
the input itself might be compromised, but "garbage in, garbage out". I
doubt this spec will prevent users from falling for phishing attacks. :)

> -- 4.2.2:
> 
> Can we have a URI-ID example? (and maybe an explanation why the HTTP example
> doesn't use one?)

Yes, we'll add that, following RFC 5922 (although that doesn't have enough
examples to borrow from).

> -- 4.3, 4th bullet item:
> 
> An example would be helpful here.

Yes, this goes along with the other URI-ID examples.

> -- 4.4, rule 1:
> Why not MUST NOT?

Do you mean "why not MUST" (instead of SHOULD) for checking of the service
type?

> -- 5.1:
> 
> Should this doc mention anything about the ability to unpin?

It's probably worth adding a sentence aobut that to the security note in
Section 4.6.4.

> *** Nits/editorial comments:
> 
> -- 1.1, paragraph 1: "...visible face of the Internet consists of services
> that employ a client-server architecture..."
> 
> This seems a little overstated. Client-server applications are certainly
> common, but they don't represent all common uses of the Internet. (Or do I
> misinterpret what you mean by "visible face"?)

You're right, "largely consists" is more accurate.

> "references some conception... of... identity"
> 
> I'm not sure what that means. Can you state this more plainly? Maybe "concept
> of identity" or "idea of identity"? (I realize "conception" can mean
> "concept", but it sounds strained to my mental ear.)

How about "notion"?

> -- 1.2, Paragraph 1: "document does not supersede the rules for certificate
> issuance or validation provided in [PKIX]"
> 
> If this document does not supercede PKIX, then that also means that PKIX is
> authoritative on any point for which is draft may be in conflict with it,
> right?

Yes indeed.

> "Specifically, in order to ensure proper authentication, application clients
> need to verify the entire certification path, because this document addresses
> only name forms in the leaf server certificate, not any name forms in the
> chain of certificates used to validate the server certificate."
> 
> Sentence hard to parse. Can it be broken up or simplified?

I think this is better:

   This document does not supersede the rules for certificate issuance
   or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
   on any point that might also be discussed in this document.
   Furthermore, [PKIX] also governs any certificate-related topic on
   which this document is silent, such as certificate syntax,
   certificate extensions such as name constraints and extended key
   usage, and handling of certification paths.

   This document addresses only name forms in the leaf server
   certificate, not any name forms in the chain of certificates used to
   validate the server certificate.  Therefore, in order to ensure
   proper authentication, application clients need to verify the entire
   certification path.

> -- 1.2, Paragraph 2: "existing application protocols"
> 
> Probably worth tying that to a point in time, as in "application protocols
> that were specified prior to the publication of this BCP"

Fixed.

> -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a
> space."
> 
> I don't see any $'s

Yes, that was an artifact of the editing process. Removed.

> -- 1.5, definition of "delegated domain":  "connecting to the source domain"
> 
> Is connecting to really the term you want here? Maybe "associated with"? In
> the context of this draft, I'm afraid people will think of connection in terms
> of tcp connections, etc.

Changed to "communicating with"

> -- 1.5, definition of "subject name"
> 
> Is there a definition or reference for "composite name"?

Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5**
specs.

> -- 1.6:
> 
> I don't know if it matters, but I usually see contributors and acknowledgments
> sections near the end. It seems sort of abrupt to find them imbedded between
> technical content sections.

This document was not the product of a WG so we probably wanted to show that
it has received wide-ranging reviews. I'm fine with moving that to the end.

> -- 3.1, 1st paragraph:
> 
> It's probably worth emphasizing that the rules are often cumulative.  I think
> someone thinking about these for the first time might not grasp that until
> they see examples later in the doc.

I've added the second sentence to this paragraph:

   When a certification authority issues a certificate based on the
   fully-qualified DNS domain name at which the application service
   provider will provide the relevant application, the following rules
   apply to the representation of application service identities.  The
   reader needs to be aware that some of these rules are cumulative and
   can interact in important ways that are illustrated later in this
   document.

> -- 4.3, implementation note: "although such behavior is not forbidden by this
> document"
> 
> The "SHOULD stop the search" language in previous paragraph implies that you
> SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's
> strongly discouraged. The implementation note makes it sound more like it is
> merely out of scope.

It's difference between:

1. Search for X and stop once you've found it.

and

2. Search for X and stop once you've found it. Then search for Y.

> -- 4.3, 4th bullet item
> 
> does the ABNF or URI reference define "reg-name" as well as "scheme"?

Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or mere host
name.

> That 
> seems ambiguous. If not, then it might be helpful to have an expansion,
> definition, or reference for "reg-name".

Clarified as follows:

   o  For a reference identifier of type URI-ID, the DNS domain name
      portion is the "reg-name" part of the "authority" component and
      the application type portion is the scheme name matching the
      [ABNF] "scheme" rule from [URI] (not including the ':' separator);
      note that this document specifies that a URI-ID always contains an
      "authority" component whose "host" subcomponent contains a "reg-
      name" (matching only the "reg-name" rule from [URI] limits
      verification to DNS domain names, differentiating a URI-ID from a
      uniformResourceIdentifier entry that contains an IP address or a
      mere host name, or that does not contain an "authority"
      component), and that extraction of the "reg-name" might
      necessitate normalization of the URI (as explained in [URI]).

> -- 4.4:  "Furthermore, if the client supports presented identifiers that
> contain the wildcard character ¹*¹, we define a supplemental rule for
> so-called "wildcard certificates".
> 
> I think the definition will stay there regardless of the intent of the client
> :-)  Perhaps something to the effect of "... We define a supplemental
> rule...which may be used by clients that support wildcards."

Heh. Corrected to:

   Furthermore, to meet the needs of clients that support
   presented identifiers containing the wildcard character '*', we
   define a supplemental rule for so-called "wildcard certificates".

Thanks again for your review. Jeff and I will confer regarding open issues
and then reply further.

Peter

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 6 Dec 2010 13:23:47 -0600 (GMT-06:00)

Ben and all,

  Very good questions all IMO.  Thanks for asking them!  >:)

-----Original Message-----
>From: Ben Campbell <[email-masked]>
>Sent: Dec 6, 2010 11:19 AM
>To: [email-masked]
>Subject: [certid] Gen-ART LC Review of	draft-saintandre-tls-server-id-check-11
>
>Summary: This draft is almost ready for publication as a BCP. I have a few questions and comments that I think should be considered first, as well as a few editorial comments.
>
>*** Major issues:
>
>-- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to see more discussion around URI-IDs. These seem to me to be the most complex ID type to get right, but there are no examples and limited discussion. Picking on SIP, purely as an example for which I have a passing familiarity: Would a SIP reference identity match a SIPS URI-ID in a certificate? Do I put both a URI-ID and an SRV-ID in my reference set and/or certificate?  How do I handle the fact that I sometimes need to do a NAPTR query, before the SRV query depending on whether I know the transport protocol? (I realize SIP already defines cert ID matching, but what would I do for a new application protocol URI with similar properties?)
>
>I wonder if the answer is that such things are scheme specific, and that its hard to say much about the generic handling of URI-IDs. If so, it might be worth mentioning that, and maybe discuss what things the designer of a new scheme should keep in mind.
>
>*** Minor issues:
>
>-- 1.2, last paragraph:
>
>Nothing normative here? Do we think that protocol designers SHOULD reference document instead of rolling their own? For example, would you expect additional IESG or SECDIR scrutiny for a new spec that rolls its own rather than referenda this? As stated, this paragraph makes it sound like this is something designers could use, rather than something designers should use. It seems like a BCP might take a stronger position.
>
>-- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related technologies such as [S-NAPTR], since such identifiers cannot be validated in a trusted manner in the absence of [DNSSEC]."
>
>Does that mean validation of a source domain that will be used to construct a NAPTR request is out of scope, or just validation against the result of a NAPTR query? (I note SIP may require the first).
>
>
>-- 2.3, paragraph 1:
>
>-- 2.3, paragraph 3: "application service is identified by a name or names carried in the subject field and/or in one of the following identifier types"
>
>May be identified, right? Since, as you mentioned earlier, it is common to identify a service with a name plus service designator, and only the SRV-ID and URI-ID intrinsically do this.
>
>-- 3.1, rule 3:
>
>What happens when you have multiple schemes that are defined to refer to the same  resource. For example, SIP and SIPS? Does a SIP URI-ID match an otherwise identical SIPS URI-ID? (Maybe this should be left to the URI definitions themselves, but it might be worth mentioning the complication somewhere.)
>
>This pattern recurs throughout the document. Can you elaborate on what you mean by "profile"? Normally I think of a "profile" as defining a subset of choices for some particular application. But if a profile relaxes a requirement (i.e. encouraging something that is a SHOULD NOT here), that's not really a subset.  Are you referring to an application protocol spec that refers to this document? Updates to this document? (I'm not sure if this should count as a minor issue or an editorial comment. It depends on whether its just a confusion around the word choice, or whether you have something specific in mind that I did not grok).
>
>-- 3.1, rule 6:
>
>Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in examples? The example does seem to make sense, but it makes me wonder if the SHOULD NOT would be better placed on the client verification process not the cert generation process.
>
>--4.2.1, paragraph 3:
>
>It's probably out of scope, but it might be useful to offer some guidance on how ensuring the extraction is "not subject to subversion" is not always trivial. For example, if you got your input URI by clicking on a link in a phishing email, that can be almost isomorphic to using a delegation from a non-trusted source.
>
>-- 4.2.2:
>
>Can we have a URI-ID example? (and maybe an explanation why the HTTP example doesn't use one?)
>
>-- 4.3, 4th bullet item:
>
>-- 1.1, paragraph 1: "...visible face of the Internet consists of services that employ a client-server architecture..."
>
>This seems a little overstated. Client-server applications are certainly common, but they don't represent all common uses of the Internet. (Or do I misinterpret what you mean by "visible face"?)
>
>I'm not sure what that means. Can you state this more plainly? Maybe "concept of identity" or "idea of identity"? (I realize "conception" can mean "concept", but it sounds strained to my mental ear.) 
>
>
>-- 1.2, Paragraph 1: "document does not supersede the rules for certificate issuance or validation provided in [PKIX]"
>
>If this document does not supercede PKIX, then that also means that PKIX is authoritative on any point for which is draft may be in conflict with it, right?
>
>"Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate."
>
>Probably worth tying that to a point in time, as in "application protocols that were specified prior to the publication of this BCP"
>
>-- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a space."
>
>I don't see any $'s 
>
>Is connecting to really the term you want here? Maybe "associated with"? In the context of this draft, I'm afraid people will think of connection in terms of tcp connections, etc.
>
>I don't know if it matters, but I usually see contributors and acknowledgments sections near the end. It seems sort of abrupt to find them imbedded between technical content sections.
>
>-- 3.1, 1st paragraph:
>
>It's probably worth emphasizing that the rules are often cumulative.  I think someone thinking about these for the first time might not grasp that until they see examples later in the doc.
>
>-- 4.3, implementation note: "although such behavior is not forbidden by this document"
>
>The "SHOULD stop the search" language in previous paragraph implies that you SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's strongly discouraged. The implementation note makes it sound more like it is merely out of scope.
>
>-- 4.3, 4th bullet item
>
>does the ABNF or URI reference define "reg-name" as well as "scheme"? That seems ambiguous. If not, then it might be helpful to have an expansion, definition, or reference for "reg-name".
>
>-- 4.4:  "Furthermore, if the client supports presented identifiers that contain the wildcard character '*', we define a supplemental rule for so-called "wildcard certificates".
>
>I think the definition will stay there regardless of the intent of the client :-)  Perhaps something to the effect of "... We define a supplemental rule...which may be used by clients that support wildcards."
>_______________________________________________
>certid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/certid

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

---

From: =JeffH <[email-masked]>
Date: Wed, 08 Dec 2010 14:56:44 -0800

> I'm wondering if we ought to add an "implementation note" at the end of
 > [S3.1] where we mention why one might have a cert with multiple presented
 > identifiers or a client may employ SNI.

oh, and refer to said impl note from bullet (6).

=JeffH

---

From: =JeffH <[email-masked]>
Date: Thu, 09 Dec 2010 09:32:04 -0800

PeterSA replied..
 >
 > And the wordsmithing continues...
 >
 > On 12/8/10 3:52 PM, =JeffH wrote:
 >> see way below...
 >>
 >> PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST)
 >>>
 >>> On 12/8/10 7:37 AM, Ben Campbell wrote:
 >>>>
 >>>>
 >>>> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre <[email-masked]>
 >>>> wrote:
 >>>>
 >>>>> On 12/7/10 10:45 PM, Ben Campbell wrote:
 >>>>>>
 >>>>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote:
 >>>>>>
 >>>>>>> On 12/7/10 6:35 PM, Ben Campbell wrote:
 >>>>>>>>
 >>>>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote:
 >>>>>>>>
 >>>>>>>>> Peter Saint-Andre <[email-masked]> replied..
 >>>>>>>>>>

<snippage type="major"/>

 >>>> Do you think server_name extension use is actually common enough to
 >>>> call typical? I'm not saying it's not--I don't really know one way or
 >>>> another. Otherwise, WFM.
 >>
 >> I don't think the TLS server_name extension (aka SNI) is in common
 >> enough use yet to call it "typical". There's a certain
 >> still-widely-deployed version of a certain desktop OS that doesn't
 >> support it, unfortunately.
 >
 > I had changed it to:
 >
 >       if the server hosts more than one domain then the certificate it
 >       presents might be based on a DNS domain name specified by the
 >       client when initiating communication (e.g., using a Server Name
 >       Indication during TLS negotiation as described in [TLS-EXT]).
 >
 > That seems suitably vague about how common SNI is. But per your message
 > I think this might belong in a different place.
 >
 >>> We could say "and if the server hosts more than one domain then the
 >>> certificate presented is typically based..."
 >>
 >> Upon re-reading what we presently have in -11 for [S1.1], I don't think
 >> we need to introduce in that intro paragraph the notion of
 >> disambiguating names in a multi-domain situation. I'd leave that para
 >> as-is.
 >
 > Yes, I'd already removed any mention of SNI from Section 1.1.

thx.

 >
 >> in terms of the defn for "presented identifier" in [S1.5], I'd update it
 >> like so (I don't think mentioning SNI is reasonable in that defn proper)..
 >>
 >>  presented identifier:  An identifier that is presented by a server
 >>  to a client within a PKIX certificate when the client attempts to
 >>  establish a secure connection with the server; the certificate can
 >>  include one or more presented identifiers of different types, and
 >>  if the server hosts more than one domain then the certificate might
 >>  present distinct identifiers for each domain.
 >
 > WFM.

super.

 >> [S3.1] where we mention why one might have a cert with multiple
 >> presented identifiers or a client may employ SNI.
 >>
 >>
 >> Implementation Note:  <snip/>
 >>
 >> of course, the FDA notes that the above will require generous
 >> wordsmithing before use.
 >
 > Wordsmithed as follows:
 >
 > ##
 >
 > 5.4.  Multiple Identifiers
 >
 >    A given application service might be addressed by multiple DNS domain
 >    names for a variety of reasons, and a given deployment might service
 >    multiple domains (e.g., in so-called "virtual hosting" environments).
 >    In the default TLS handshake exchange, the client is not able to
 >    indicate the DNS domain name with which it wants to communicate, and
 >    the TLS server returns only one certificate for itself.  Absent an
 >    extension to TLS, a typical workaround used to facilitate mapping an
 >    application service to multiple DNS domain names is to embed all of
 >    the domain names into a single certificate.
 >
 >    A more recent approach, formally specified in [TLS-EXT], is for the
 >    client to use the TLS "Server Name Indication" (SNI) extension when
 >    sending the client_hello message, stipulating the DNS domain name it
 >    desires or expects of the service.  The service can then return the
 >    appropriate certificate in its Certificate message, and that
 >    certificate can represent a single DNS domain name.
 >
 >    To accommodate the workaround that was needed before the development
 >    of the SNI extension, this specification allows multiple DNS-IDs,
 >    SRV-IDs, or URI-IDs in a certificate; however, it explicitly
 >    discourages multiple CN-IDs.  Although it would be preferable to
 >    forbid multiple CN-IDs entirely, there are several reasons at this
 >    time why this specification states that they SHOULD NOT (instead of
 >    MUST NOT) be included:
 >
 >    o  At least one significant technology community of interest
 >       explicitly allows multiple CN-IDs [EV-CERTS].
 >
 >    o  At least one significant certification authority is known to issue
 >       certificates containing multiple CN-IDs.
 >
 >    o  Many service providers often deem inclusion of multiple CN-IDs
 >       necessary in virtual hosting environments because at least one
 >       widely-deployed operating system does not yet support the SNI
 >       extension [TLS-EXT].
 >
 >    It is hoped that the recommendation regarding multiple CN-IDs can be
 >    further tightened in the future.
 >
 > ###

excellent smithing there, thanks.

=JeffH