On 21/06/2010 22:04, Michael Ströder wrote:
Michael Ströder wrote:
Paul Hoffman wrote:
It tells us that, when there are multiple ways to do things, and some of
those ways are known to be insecure due to repeated poor implementations,
we can say "don't do that" for the bad ways.
That's fine for me too.
But to make that more clear in this context: The draft should not discourage
completely using DCs in the subject-DN. It should only recommend not to encode
the server's hostname in the DCs.
I think the problem with that approach is the same as the use of the
word "represent" in a couple of paragraphs (as mentioned earlier on this
list): if you get some DCs (or CN for that matter), how do you know
whether or not they were meant to "represent" the hostname or something
else?
If DCs are to be used in some but not all cases to convey the hostname
to check against, then there either needs a way to disambiguate which
case is which.
In my opinion, I would split this in two cases:
- If there is a subject alt. name.: the Subject DN can be more or less
ignored (it would just be a convenience).
- If there isn't: the expectations on the DCs (or CN) in the Subject DN
have to be strict (i.e. a MUST). If we get something like "SHOULD NOT
encode the server hostname in the DCs", then the door is open to
ambiguity, and I think that's where the problems will come for
determining whether or not the certificate matches the server.
(I think that would also be compatible with the existing implementations
of RFC 2818.)
Best wishes,
Bruno.
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
