Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)

[Jacob Hoffman-Andrews <[e-mail]>]

> == COMMENTS ==
> 
> -- Section 2.2 --
> 
> "Domain Name: The label assigned to a node in the Domain Name System." AFAIK
> RFC 1034 defines it differently "The domain name of a node is the list of the
> labels on the path from the node to the root of the tree" Or are we talking
> about different "domain names" ?

Thanks, this is good feedback. I adopted language that matches the 
CA/Browser Forum Baseline Requirements, for better integration there:

 > Domain Name: The label assigned to a node in the Domain Name System.
 > Fully-Qualified Domain Name: A Domain Name that includes the labels
 >   of all superior nodes in the Domain Name System.

So FQDN matches the "list of labels" definition pretty well.

However, looking at this made me realize that this draft says "Domain 
Name" in a lot of places that should say "FQDN." I'll change all these 
to FQDN in the next draft.

> "Wildcard domain name": it would be interesting to define not only the syntax
> but also the semantic do those wildcard domain names.

These are defined in https://tools.ietf.org/html/rfc6125#section-6.4.3.

> While I am not a security expert, a TLD could add a CAA forcing all its FQDN to
> either use the CA defined in the TLD CAA RRset or add a per FQDN CAA (which may
> raise the bar for small not-so-managed domains which otherwise could have used
> a cheap and easy CA such as letsencrypt). Is it really good to climb the DNS
> tree up to the TLD? Just curious.

This is sub-optimal, but unfortunately there's no good programmatic way 
to determine where the TLD begins. For instance "example.co.uk" vs 
"example.com". The DBOUND WG is working on this problem but it's not 
solved yet. Since there's an option for subdomains to set their own CAA 
policy, the negative effects of such a choice by a TLD are not too bad.


> I would have preferred a recursive definition rather than an interative
> algorithm but this is a matter of taste ;-)

I agree, but since it's a matter of taste I decided to err on the side 
of "similar to previous algorithm" so it's easy for CAs to analyze the 
differences.