Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml

["John R Levine" <[e-mail]>]

> This document should define precisely what combination of these
> elements is sufficient for the client to accept the certificate.

If only.  Existing practice for PGP seems to be rather different from what 
the theory is ("if it doesn't look totally bogus, use it" vs "check and 
score WoT signatures against your private list") and for S/MIME it depends 
on what set of CAs are in your MUA, which in my experience is generally 
pretty stale.

Adding to the confusion, some people appear to believe that a domain is a 
reliable authority for certs for its email addresses.  (See for example 
the third paragraph in the introduction in RFC 7929 which makes no sense 
otherwise.)  Others of us don't, since the relationships between domain 
operators and mail users are incredibly variable.

If you are in the domain is authoritative camp, you can use 
DNSSEC->SRV->https as a chain of trust for the cert, or for S/MIME you can 
use DNSSEC->TLSA as a chain of trust for the signature.  If you aren't, 
you can do whatever you do now and the DNSSEC doesn't get you anything 
beyond the usual anti-spoofing.

If people agree these are the two plausible scenarios, I could easily add 
text describing them.  I don't see any chance of deciding on only one or 
the other.

> It's somewhat odd to encourage TLSA records (at SHOULD level) but a
> WebPKI valid certificate at MAY level. This is pretty much the
> opposite of standard practice for HTTPS on the Internet today. It's
> not like it's particularly onerous for someone running a Web server to
> get WebPKI valid certs.

Good point, MUST for https seems obvious.

> S 5.
> This section also needs to be fleshed out. Questions include:
>
> - You say "a blob of binary data". Do you mean that they are DER? That
>  seems implied, but it could be compressed DER or something. This
>  needs to be specified.

That's supposed to be whatever RFC 4387 did.  Looking at it, it's not 
clear to me what encoding it expects, so I agree it could use some 
clarification.

> - What is the relationship between the multiple certificates that are
>  provided? Are they alternatives? Are some of them intermediates that
>  can be used to validate the EE certificate (this is commonly
>  required)? If so, which one is the EE cert?

Again, this is out of RFC 4387.  I was under the impression that the 
client could look at the certs and see what chained to what.

> - Are there any requirements about the format of the various subject
>  name fields? Say I ask for "[e-mail]" and get a cert for
>  "[e-mail]". What do I do?

RFC 4387 again.

> This section about how to publish domain-operated CA certificates kind
> of seems like an add-on and needs to be fleshed out quite a bit
> more. For instance, why aren't you defining the same mechanism for
> PGP, as they seem analagous in this case. If you want to define TLSA
> records for CA certs for e-mail that seems like it should probably be
> the subject of a separate document.

I suppose I could wave my hands and say that the domain publishes an 
OPENPGPKEY record with postmaster@<domain>, but it's not clear to me 
whether anyone would care.  S/MIME signatures are (as I understand it) 
supposed to be deterministic, if you trust the signer, you trust the cert, 
while WoT is squishy.  As far as putting it in a separate document, I 
wouldn't object but it's not clear what the advantage would be.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.