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

[Eric Rescorla <[e-mail]>]

On Sun, Aug 21, 2016 at 10:51 AM, John Levine <[e-mail]> wrote:

> >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.
>
> Sure, if that were feasible.  I see no chance at all of getting a
> sufficient agreement that domains are authorititative, or that they
> aren't.  From what I've seen so far, few people have even thought
> about it, and fewer still outside the context of whatever mail system
> they personally are running.  People at gmail said they're interested
> in this, so I can ask if they've thought about it in the context of
> a very large public mail system.
>

This seems like a potential indicator that this technology is not yet ready
for standardization.


>> Good point, MUST for https seems obvious.
> >
> >I don't just mean MUST for HTTP, but also encouraging the use of valid
> >certs.
>
> OK.
>
> >> 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.
>
> I am not a great pkix expert, so pointers and suggestions are welcone.


OK.

I think the high order bit here is that there are two basic kinds of certs
in play:

- EE certs (i.e., the ones that allegedly correspond to the user in
question)
- Intermediate CA certs that somehow could be used to construct a chain to
the EE.

It's pretty common, at least on the Web, to have situations where there is
1 or more
intermediate between the trust anchor and the EE cert (e.g., in the case
where CAs
are cross-signed), which is why you need the second bucket. Unfortunately,
sad
experience with the Web indicates that it's not really possible to
construct a chain
which is verifiable to all clients, so it's probably best to just have this
be a "you might
be interested in" class.

As I said previously, I kind of suspect that 4387 just meant that the certs
were all
alternative EEs, but then you probably want some other way to get the
intermediates
for the reason listed above, but in any case you shouldn't just have them
all in the
same bucket. So, what's probably best is to concretize this by saying that
this
bucket is just for EE and then define some other mechanism for getting
intermediates.

-Ekr