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

From: "John R Levine" <[email-masked]>
Date: 22 Jul 2016 12:54:26 +0200

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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 Jul 2016 14:50:35 +0200

On 22 July 2016 at 12:54, John R Levine <[email-masked]> 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.

I would like to see some thorough review of this work.  AD sponsorship
is not appropriate in my opinion.

Primarily, there needs to be adequate security review.  There are
several big risks that this draft skirts and good review, and maybe
even analysis, of this is important.

The draft appears to violate RFC 7320.  That suggests that wider
review of other areas of this is needed.

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2016 16:58:37 -0000

More review is nice, but useful review needs to be more than "I don't
trust this."

>even analysis, of this is important.

This draft describes a way to publish and retrieve S/MIME and PGP
keys.  The keys are the exact same ones you can get in other ways now,
and the draft goes to considerable lengths to say that, just like with
keys you get any other way, it's up to the client to decide how much
credence to give to them.  Any security problems with bogus keys are
the same ones we've already been dealing with as long as there have
been PGP and S/MIME.

If it appears that this draft is asserting that the keys are "real"
because the domain says so, it's trying very hard not to say that, so
it'd help to know what was confusing.  (Attempting to specify the
relationship between a domain and its users is a hopeless swamp of
despair where we're not going.)

>review of other areas of this is needed.

I presume this is a reference to the URL paths in section 3.  They are
imported verbatim from RFC 4387 which was published ten years ago.
Since they're not new, it would be helpful to clarify under what
circumstances we're not allowed to use specs from existing standards
track RFCs.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Jul 2016 14:32:54 +0200

> More review is nice, but useful review needs to be more than "I don't

I was merely reacting to the implication that this was good enough.
It may well be.

Consider this a promise to look at this a little more closely than I
have already.