On Sun, Mar 24, 2013 at 12:52:14AM +0000, Viktor Dukhovni wrote:
> > ,----< 2 -- Certificate usage 2 ... >
> > | The target certificate MUST pass PKIX certification path validation,
> > | with any certificate matching the TLSA record considered to be a
> > | trust anchor for this certification path validation.
> > `----
> >
> > means that the cert has to be included in the tls startup negotiation;
> > it cannot be elided.
>
> I take it you read the phrase "with any certificate matching the
> TLSA record... " to mean that such a certificate must come from
> the server in the server SSL HELO. If I squint hard enough, I can
> read it the same way, but I could also suppose that the PKIX
> validation path in question was in part constructed by the verifier,
> and so no explicit requirement for the server to provide the
> certificate.
This looks even more important with "2 1 0", since we find in:
https://tools.ietf.org/html/rfc5280#section-6.1.1
(d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path. The trust anchor
information includes:
(1) the trusted issuer name,
(2) the trusted public key algorithm,
(3) the trusted public key, and
(4) optionally, the trusted public key parameters associated
with the public key.
and in
https://tools.ietf.org/html/rfc5280#section-6.1
(b) certificate 1 is issued by the trust anchor;
Since, as James points out, we have in:
https://tools.ietf.org/html/rfc6698#section-2.1.1
2 -- Certificate usage 2 is used to specify a certificate, or the
public key of such a certificate, that MUST be used as the trust
anchor when validating the end entity certificate given by the
server in TLS. This certificate usage is sometimes referred to as
"trust anchor assertion" and allows a domain name administrator to
specify a new trust anchor -- for example, if the domain issues
its own certificates under its own CA that is not expected to be
in the end users' collection of trust anchors. The target
certificate MUST pass PKIX certification path validation, with any
certificate matching the TLSA record considered to be a trust
anchor for this certification path validation.
a clear requirement to build a PKIX trust chain. Since the word
"issued" (not the same as "signed") implies a name comparison not
a signature check, in order to use an "IN TLSA 2 1 0 ..." RR, we
need to map the trust-anchor's public key to its subject name, which
is only possible when the corresponding certificate must appears in
the peer's chain!
Now if that's a requirement, then "2 1 0" use-case is simply a waste
of bits in DNS, we get the same result via "2 1 1", since both
match the same element of the chain, but 2 1 1 is substantially
more compact.
------
SO: What's the story wrt. requiring the trust-anchor certificate in
the server's chain? Is my analysis correct? Should the text be
more clear?
------
> At some noticeable complexity cost (though not a lot of lines of
> code), I've added full support for "2 0 0" and "2 1 0" TLSA records,
> so now I can verify trust chains that omit the corresponding issuing
> certificate and begin with something signed by the TA.
My current "2 1 0" support checkes "signed by TA" not "issued by
TA", is that a valid interpretation of "2 1 0"? There is a real
tension here between robustness of the protocol in the face of
sloppy administrator practices (neglecting to include the top signer
in the chain) and the stated requirement to do "PKIX validation".
Which do you want? If it's strict "PKIX", then the TA cert is
required and then "2 1 0" devolves to "2 1 [12]" and is redundant
(modulo SHA2 2nd-preimage attacks which break so much else that it
is not worth considering other than future introduction of SHA3 or
beyond matching types via the IANA registry).
If "2 1 0" is not strict PKIX, and supports chains merely signed
by a TA, but not necessarily "issued" by that TA, then 2 1 0 has
some meaning, but violates the "issued by TA" requirement on the
top element of the chain.
Implementing the TA portion of the standard is uncovering murky
corner cases that I don't see clearly covered in 6698.
The leaf certificate use cases all work. None of the certificate
usage "2" (other than "2 0 0") cases work at all unless the TA
certificate is absolutely required in the peer's chain, but even
"2 0 0" is DNS-hostile due to excessive RRset sizes.
If one takes certificate usage 0 at face value, then one is required
to be able to build a PKIX chain for all its incarnations without
any DANE RRset input, and then with all the right material already
hand, there are no problems with "1 x y".
For SMTP however, the requirement on the verifier of having at hand
"a complete CA certificate set" (whatever that means) is untenable.
There is no human to click "OK" when the CA list is incomplete,
and administrators will quickly disable DANE if it routinely breaks
mail delivery to a non-trivial fraction of destinations.
So I need to ignore the requirement for pre-existing shared CA trust
with certificate usage "0" and treat it as equivalent to "2". Thus
I'm left with either (amended 6698 or draft-ietf-dane-smtp):
- All DANE-enabled TLS servers MUST respond with server SSL HELO
chains that contain the associated TA certificate (for both
usage 0 and 2). In this case "2 0 0" and "2 1 0" are both
silly, "2 0 1" or "2 1 1" do the same job much better. And,
for SMTP at least, "0 0 0" and "0 1 0" meet the same fate.
OR
- I can support only the DNS-hostile "0 0 0" and "2 0 0" and
also the more compat "0 1 0" and "2 1 0" provided I re-interpret
"issued by TA" as "signed by TA" in the case of full public-key TAs.
What I have implemented so far is the second alternative. I am a bit
stunned by the silence of the majority of the list. Are my questions
to hard, too annoying, or just inconveniently timed?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
