On Fri, 30 May 2014, Viktor Dukhovni wrote:
The bare public key document could refer to an ERRATA for 6698 that
states an ASN.1 SPKI structure is to be considered a "PKIX certificate"
in the context of TLSA certificate usage selectors?
Two problems with that:
* The ERRATUM will likely be rejected, because the restriction was
intentional.
There is/was no restriction. It is a clarification. Note that the
certificate type 3 explicitely excludes "PKIX validation" to allow for
a 'certificate' containing just a SPKI, and now what normal "PKIX
validation" would deem as "minimal required".
* This is the obvious part of how to use "oob public key" with
DANE, and need hardly be explained. The non-obvious part is the
need to only signal "oob public key" support in the client
when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?"
records.
This is the third time you mention this and the third time I have to ask
you why. It is perfectly normal to NOT HAVE TLSA RECORDS and rely on a
firmware public key, and still signal and use "oob public keys". Please
try and explain why you are trying to add restrictions on the set of
TLSA records to support "oob public key" (which can happen on its own,
along with regular full cert support, with or without DANE)
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
