Subject: [dane] Appendix A.1 - Certificate Usage 0 only (Re: draft-ietf-dane-protocol-19.txt typos and minor fixes)

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:40:37 +0200

On 12. 4. 2012, at 19:30, John Gilmore wrote:
> Appendix A.1 is totally focused on CA-based examples, and provides no
> guidance to users who want to deploy non-CA-based DANE.  Nor does it
> provide any guidance for domain administrators who are not sure
> whether they want CA-based DANE or non-CA-based DANE.  I had written
> and submitted text about this, but none of it made it into the
> document.

Section A.1 says:

   When creating TLSA records with certificate usage 0 (CA Certificate)
   or usage 2 (Trust Anchor), one needs to understand the implications
   when choosing between selector type 0 (full certificate) and 1
   (SubjectPublicKeyInfo).  A careful choice is required because
   different methods for building trust chains are used by different TLS
   clients.  The following outlines the cases that one ought to be aware
   of and discusses the implications of the choice of selector type.

and here comes the important part:

   Certificate usage 2 is not affected by the different types of chain
   building when the end entity certificate is the same as the trust
   anchor certificate.

> The appendix is written as if there is not even an option in DANE to
> avoid using CAs.

So yes, section A.1 is written to help deployment for Certificate usage 0,
because this one is the complicated one.

I haven't seen any support from the working group on this topic.  If this
isn't case please speak now.  And in that case, please accompany your +1
with some text you would like to see in Section A.1.

Chairs think the section is fine as is.

And final note:

> One might reasonably come to the conclusion that
> committee members associated with CAs are deliberately slanting the
> readers of the document toward their business model.  This is not
> appropriate in an RFC.

Please refrain from flaming here.  Ad hominem arguments are not appropriate
and they will not help you make stronger argument.  Thank you.

Ondrej
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 17:52:30 +0200

On 13. 4. 2012, at 2:58, Mark Andrews wrote:
> We should recommend that tools that convert certificates to TLSA
> records "SHOULD" support emitting the record in RFC 3597 format in
> addition to TLSA presentation format.

I don't think this is appropriate to say in the RFC.  Tools are free
to do whatever they want.

We could add something like (copied from RFC4034):

   The Type Covered field is represented as an RR type mnemonic.  When
   the mnemonic is not known, the TYPE representation as described in
   [RFC3597], Section 5, MUST be used.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 May 2012 18:12:04 +0200

Also here:

Just to be explicit, I consider that there was no consensus for a change.

O.

On 3. 5. 2012, at 17:40, Ondřej Surý wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 May 2012 10:20:19 +1000

In message <[email-masked]>, =?utf-8?Q?Ond=C5=99ej
> to do whatever they want.

If we want interoperability between tool sets it is needed.  Not
everything is over the wire.  Sometimes you are dealing with text
files as the data interchange mechanism.  Requiring everything to
be able to read and emit the LCD format achieves that.  It doesn't
have to be the default emitted but it MUST be able to be emitted.

We would be negligent as software engineers if we don't do that.

>  Ond=C5=99ej Sur=C3=BD -- Chief Science Officer
>  CZ.NIC, z.s.p.o.    --    Laborato=C5=99e CZ.NIC
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]