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

[Eric Rescorla <[e-mail]>]

On Sun, Aug 21, 2016 at 9:39 AM, John R Levine <[e-mail]> wrote:

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


Yeah, that seems like it might be OK in some sort of informational document
describing common practice, but this document is asking for Standards
Track, and in that situation it seems like actually specifying one class of
behavior is the superior direction.


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.


I don't just mean MUST for HTTP, but also encouraging the use of 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.
>>
>
> 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.


The text in 4387 is not maximally clear. It appears that perhaps the idea
is that this is just EE certs. If it's a mix of multiple EE and chain
certs, it's not reasonable to expect the RP to make sense of it. In any
case, this text should be clear.


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


It seems like a citation to the relevant section would be in order here.


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


As usual, functional decomposition.

-Ekr


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