Subject: [Uta] AD review of draft-ietf-uta-email-tls-certs-05

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 12:53:17 +0000

Hiya,

Sorry for being slow getting this done. My AD review of this
is below. Please consider my comments as last call comments.
I have requested last call for this one so you should see the
announcement of that shortly.

- section 3, first list, bullet 1: what's option (c) there mean?
wasn't clear to me.

- typo: "an email server certificates"

- section 3, 2nd list, bullet 3 - is that MUST NOT really needed? if
URIs are not used, might it be better to be silent? (In case someone
does figure out a use?)

- section 3, 2nd list, bullet 4 - afaik, CN is what is mostly
actually used.  Shouldn't we recognise that reality with more than a
MAY? It's been more than a decade since PKI folks started to want to
not use CN and that's just not worked. (Or am I wrong and CAs/MUAs
are finally seeing CN not used?)

- section 4, bullets 1&2 - do we have any evidence that these MUSTs
will be honoured? If not, or if we have eveidence that they will be
ignored, then is it really a good idea to include such RFC6919-isms?
(A change here would also percolate to sections 3 and 5 I guess.)

- I think the answer is "no," but I'll ask anyway:-) Many mail
service providers use names like mail.example.com, smtp.example.com,
imap.example.com etc. Would it be useful for this document to
encourge the use of specific hostname parts for specific functions?
(Hostname part is probably the wron term, I mean the smtp, imap,
mail parts of those names)

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Nov 2015 14:10:58 +0100

Hi Stephen,

Just on this point...

> mail parts of those names)

I agree with you that the answer is "no".  I don't think we want to
create some sort of reserved word list within the domain name itself. 
But why do you ask?  Do you perceive such a need?

Eliot

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 09:18:07 -0500

Sent from my iPhone

> On Nov 20, 2015, at 7:53 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Hmm, they were used in all of the CAs I set up and certificates I have needed to use, adding the host name there.  Sometimes there were CNAMEs added in an extension.  What are you seeing used instead of CN/DN?
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 14:23:33 +0000

> But why do you ask?  Do you perceive such a need?

I wasn't thinking of a reserved word list, but more like a
recommendation to mail service deployments, CAs and MUAs to
say please do use e.g. smtp.example.com for submission (and
not mail.example.com) and to please use imap.example.com
etc. The possible benefit would I think be an increase in
the success rate when MUAs guess those names starting from
a mail address, for cases where the SRV thing hasn't been
done. But, I still think the answer is no;-)

S.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Nov 2015 14:31:32 +0000

Hi Stephen,

> done. But, I still think the answer is no;-)
IMHO, this is something for the to-be-written mail service discovery 
document, which is not this spec.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 14:54:37 +0000

On 20/11/15 14:18, Kathleen Moriarty wrote:
>>> actually used.  Shouldn't we recognise that reality with more
>>> than a MAY? It's been more than a decade since PKI folks started
>>> to want to not use CN and that's just not worked. (Or am I wrong
>>> and CAs/MUAs are finally seeing CN not used?)
> Hmm, they were used in all of the CAs I set up and certificates I
> have needed to use, adding the host name there.  Sometimes there were
> CNAMEs added in an extension.  What are you seeing used instead of
> CN/DN?

Yeah, CN seems to still be ubiquitous, though Alexey reminded me
(off list) that the dNSName SAN is also widely used. So all in all
section 4 is probably ok, if we consider the SRV stuff as something
we'd like to see deployed, but have yet to see deployed.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Nov 2015 14:56:44 +0000

I would say that subjectAltName is ubiquitous, and CA's are reluctant to stop using CN because it might break someone, somewhere.

At least in my experience at work and on OpenSSL.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 10:02:35 -0500

> I would say that subjectAltName is ubiquitous, and CA's are reluctant to stop using CN because it might break someone, somewhere.

Pre-caffeine, I couldn't think of the attribute for holding CNAMEs,
thank you.  Path validation, I think requires both, but if a CNAME
shows up in subjectAltName, and everything else checks out, you are
good to go.  I think (pretty sure) validation requires a check first
for CN though, then it goes through the alternate names.  RFC5280
hasn't changed or is there an update I missed that changes proper path
validation?  I would guess things would break without CN values
included.  Anyway, I think we are good on this one now.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "John Levine" <[email-masked]>
Date: 20 Nov 2015 15:55:21 -0000

>document, which is not this spec.

How does that differ from RFC 6186?  I'd rather encourage people to
implement the specs we already have.

R's,
John

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Nov 2015 16:26:34 +0000

Hi John,

On 20/11/2015 15:55, John Levine wrote:
> How does that differ from RFC 6186?
It isn't. But I've heard people saying that RFC 6186 is insufficient or 
needs updating.
> I'd rather encourage people to

---

From: tom p. <[email-masked]>
Date: Sat, 21 Nov 2015 12:11:38 +0000

----- Original Message -----
From: "Kathleen Moriarty" <[email-masked]>
To: "Salz, Rich" <[email-masked]>
Cc: <[email-masked]>; "Stephen Farrell" <[email-masked]>
Sent: Friday, November 20, 2015 3:02 PM
> > I would say that subjectAltName is ubiquitous, and CA's are
reluctant to stop using CN because it might break someone, somewhere.
> for CN though, then it goes through the alternate names.

RFC5539 says
"If a subjectAltName extension of type dNSName is present in the
      certificate, it MUST be used as the source of the server's
      identity."
or from draft-ietf-pce-pceps-06
"The following precedence applies: for DNS name
             validation, subjectAltName:DNS has precedence over CN; for
             IP address validation, subjectAltName:iPAddr has precedence
             over CN."
which chimes with my experience.

subjectAltName   100:    CN   nil

Tom Petch

RFC5280

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 21 Nov 2015 07:41:32 -0500

Sent from my iPhone

> On Nov 21, 2015, at 7:11 AM, tom p. <[email-masked]> wrote:
> 

I've also seen product implementations vary widely in how they implement path validation or if they do at all.  So there may be justified fear in this change from the reality of operational situations.

Thanks,
Kathleen

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 21 Nov 2015 14:52:44 +0000

Hi Stephen,

> announcement of that shortly.

Thank you for your comments.

> - section 3, first list, bullet 1: what's option (c) there mean?

This is a reference to DNSSEC/DANE or similar mechanisms, without having
an explicit reference to them.

> - typo: "an email server certificates"

Fixed, thank you.

> URIs are not used, might it be better to be silent? (In case someone

I did this mostly because RFC 6125 mentions them.

A document that figures out how to use them can update this document ;-)?

> are finally seeing CN not used?)

I don't mind switching from MAY.

If you can suggest some specific text to add (other than just switching
from MAY to something else), let me know.

Best Regards,
Alexey