On Thu, 15 Jan 2015, Viktor Dukhovni wrote:
The dane-ops draft in section 5.1 specifically extends the semantics
of "3 1 X" to cover RPK. (The reference to the RPK draft needs to
be updated to reference the published RFC).
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-12
* In Section 5.1 we update [RFC6698] to specify peer identity
matching and certificate validity interval based solely on the
basis of the TLSA RRset. We also specify DANE authentication of
raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
Certificate Usage DANE-EE(3) and selector SPKI(1).
If the text in section 5.1 of that document needs to say more, or
to be phrased differently, patches (to the XML please) welcome.
Before I send patches, we will need a discussion, because I know you
will reject the proposals I would write. The whole point of DANE-EE(3)
with selector SPKI(1) was to demote _any_ X.509 material apart from
the public key as legacy garbage. But people couldn't say that out
loud so the wording in 6698 was done in a way to make both sides of
the argument happy. As John showed, and the WG agreed to, we needed to
make that more explicit. After I presented John's draft at the meeting,
the consensus was these changes should be folded into this document as
it already updates 6698.
So instead of text stating "ignore the expiry date of the certificate",
the next needed is that for DANE-EE(3) and selector SPKI(1) everything
but the SPKI of the certificate should be completely ignored. In fact,
RFC 7250 allows for certificates that contain nothing more than SPKI.
Then, to attempt to avoid a problem with the text as it is currently
in the draft, this band-aid is specified:
Clients that employ DANE to
authenticate the peer server SHOULD NOT negotiate the use of raw
public keys unless the server's TLSA RRset includes compatible TLSA
records.
The only reason for this is because enough of the certificate wasn't
already ignored by clients not supporting raw public keys!
Also, the DANE document is not the place to specify how TLS clients
with raw key support should do TLS negotiations with extensions. The
only thing this document needs to state is "DANE-EE(3) and selector
SPKI(1) means only look at the public key, ignore everything else" and
than magically both clients that don't support raw keys but implement
this document and clients that do support raw keys and implement this
document, will work fine.
If you agree with these points, I'm happy to submit xml updates.
Perhaps it is time to move the OPS draft into LC
No. I think we need to resolve this issue first. It has been evaded for
years, from the start of the work on 6698 up to this latest draft.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
