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

Comments below:
OVERALL The trust model of this document seems confusing. Typically we
assume that certificates are self-authenticating, i.e., the
certificate can be provided to you by the attacker and you can
independently validate its acceptability. And graf 2 of section 5
implies this by talking about a signature from a CA.

However, in this protocol, you have the following additional
cryptographic protocols in play:

- A DNSSEC-signed SRV record
- A DNSSEC-signed TLSA record
- An HTTPS connection to the server
- A potentially WebPKI-valid server cert

This document should define precisely what combination of these
elements is sufficient for the client to accept the certificate. For
instance, if we have a DNSSEC-signed SRV that leads to a WebPKI valid
HTTPS server which serves a self-signed cert for the user, is that
acceptable? This reflects a completely different trust model from that
assumed by S/MIME traditionally. Another way to ask this question is:
is this an untrusted directory or is it a substitute for a PKI for
e-mail certificates.

This also goes to the question of whether this document should be in
the security or ART area.

DETAIL
S 2.
Your requirements for what cryptographic technology is used here are
all non-MUSTs, but how important they are depends entirely on the
trust model (see above). If the certs are self-authenticating and this
is just an untrusted directory, then this is largely an operational
question. However, if it is acting as a substitute CA, then actually
having a cryptographically valid chain of inference is imperative and
there need to be some MUSTs here.

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.

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.

- 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?

- Are there any requirements about the format of the various subject
  name fields? Say I ask for "bob@example.com" and get a cert for
  "alice@example.invalid". What do I do?

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.

-Ekr

On Fri, Jul 22, 2016 at 3:54 AM, John R Levine <johnl@taugh.com> wrote:

> The WG seemed OK with it.  After talking to people who plan to implement
> it I updated the draft with some editing fixes and a longer security
> section.
>
> This also seems appropriate for AD sponsored, please.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>