Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

So, while I have sure that I have the details partly wrong, consider the
case of people doing a PGP certificate set here.

They could/would use DANE-EE in the event that the key ring was self-signed.
This is the key to be matched and trusted.

However they would not use DANE-TA in the event that a key ring that was
self-signed was to be used to validate a second key wrong.  In this case
there is a root of trust (i.e. a TA) and then a second level signed PGP key
which is used in the TLS session to do the appropriate things.  This allows
for the TLS key to be rotated more frequently.  But there is no PKIX
validation in this case and thus the use of DANE-TA, which seems logical, is
wrong.

Jim

> -----Original Message-----
> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of
> Viktor Dukhovni
> Sent: Sunday, October 06, 2013 3:48 PM
> To: dane@ietf.org
> Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
> 
> On Sun, Oct 06, 2013 at 02:38:50PM -0700, Jim Schaad wrote:
> 
> > 5.  As I have stated before, I am not a fan of using DANE-TA for value
2.
> > To me this loses the fact that there will be PKIX processing that
> > occurs with this section.  I would strongly recommend that this become
> PKIX-TA.
> 
> I think that would confuse almost everyone.  The "PKI" part of PKIX
carries
> inappropriate in this context mental baggage.
> 
> Yes, any trust-anchor implies validating certificate chains, performing
name
> on the leaf, ...  Thus the mechanics of validating usage 2 associations
are
> very similar to the mechanics of doing the same with an a-priori
configured
> public CA trust anchor.  Alas, when one hears PKIX, the associated mental
> baggage includes the full panoply of public CAs and not does evoke the
> decentralized DANE model.
> 
> Thus "TA" is IMHO already sufficient to imply all the relevant technical
> features, without evoking unwanted mental associations.
> 
> > The use of PKIX-TA for the value of 0 never made any sense since there
> > is not trust anchor decision that is associated with the certificate
> > in this record.  The only two records currently that have a trust
> > anchor, as oppose to a constraint, component are 2 and 3.
> 
> Here, I've already agreed with you upthread, I think PKIX-CA is better
here
> (Paul Hoffman disagreed, but frankly I am not sure how his response
applies
> to the question at hand).
> 
> --
> 	Viktor.
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane