Subject: [dane] Expressive Short names for TLSA Record fields

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 1 Aug 2013 12:36:11 -0400

I think the best way to address this communication problem is to write a ID that defines the terms, and updates the IANA registry by adding a column 
with the short name. 

Value 	Short Description 	Reference 
0	CA constraint	[RFC6698]
1	Service certificate constraint	[RFC6698]
2	Trust anchor assertion	[RFC6698]
3	Domain-issued certificate	[RFC6698]

Suggested names: 0 = PKIX-Cert,  1 = PKIX-TA,  2 == DANE-TA , 3 == DANE_Cert 

For the selectors
Value 	Short Description 	Reference 
0	Full certificate	[RFC6698]
1	SubjectPublicKeyInfo	[RFC6698]

0   = Cert,   1  === Key 

For the digest algorithms we will just use the algorithm names SHA-256 and SHA-512. 
Feel free to suggest better names, 

	Olafur

---

From: Bry8 Star <[email-masked]>
Date: Thu, 01 Aug 2013 19:09:38 -0700

If i may suggest:
CAD or C_A_D or C-A-D as short for "Certificate Association Data" field.
Then for example, for TA TLSA type of lines, we can/may use at end,
CAD_TA or CAD-TA.
For DANE_cert types, we can/may use at end, CAD_DI or CAD-DI.

For selector "1", may i suggest "PKey" or "pKey", instead of "Key".
"SPKI" can also be used. "SPKey" may be more meaningful.

For selector "0", may i suggest "Full_Cert", or "fCert".

Currently, Usage 3, says checking cert chain/path is optional, so
pls consider to add another usage case, for example, usage 4 for
domain-issued cert, where zone/domain owner/operator can add
domain-issued cert and say/tell clients to check its FULL path/chain
by collecting/using other dane/TLSA RRs from DNS RRs. So that, ALL
certs in a cert chain/path, can be verified using DANE.  Also
suggesting to consider to add another usage type for declaring
Intermediate Authority certs including its position in a cert
path/chain (i've posted a such proposal some time earlier).

Received from Olafur Gudmundsson, on 2013-08-01 9:36 AM:
> 
> I think the best way to address this communication problem is to write a ID that 
> defines the terms, and updates the IANA registry by adding a column
> with the short name.
> 
> 0	CA constraint	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 1	Service certificate constraint	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 2	Trust anchor assertion	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 3	Domain-issued certificate	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 
> 
> 0	Full certificate	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 1	SubjectPublicKeyInfo	[RFC6698 <http://www.iana.org/go/rfc6698>]
> 
> 
> 0   = Cert,   1  === Key
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Aug 2013 03:49:11 -0400 (EDT)

> 1	SubjectPublicKeyInfo	[RFC6698]

Agreed here, as I proved how confusing it is yesterday :)

> Feel free to suggest better names,

Based on my experience with IKE configuration syntax in the last decade,
this seems a really bad idea. People have assumed "sha" is "sha1". When
you say "sha-256" people now know it is sha2 because sha1 does not have
256 bits. But for sha3 that won't be true.

We really aught to keep "sha" to be an alias to "sha1" only, and always
use "sha2" and sha3" prefixes.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Aug 2013 10:28:57 +0200

> I think the best way to address this communication problem is to write a ID that defines the terms, and updates the IANA registry by adding a column 

As mentioned off-list, I think this is a grand idea….

Sometimes, in some sort of other document, someone should write up a recommendation to always use enums or named values or something.
Even if you only start off with 2 values, eventually you add more and it all gets confusing. "You connect over FOO (6)" is much clearer than "You connect over 6", even if you figure everyone will remember what 6 is…

W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 5 Aug 2013 21:41:03 +0200

> Suggested names: 0 = PKIX-Cert,  1 = PKIX-TA,  2 == DANE-TA , 3 == DANE_Cert 

Although I assume you mean:

0 = PKIX-TA
1 = PKIX-CERT
2 = DANE-TA
3 = DANE-CERT

	jakob

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 6 Aug 2013 07:50:04 -0400

> Although I assume you mean:

Yes I do, 

	Olafur

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Aug 2013 13:03:41 +0100

>> Although I assume you mean:

Names are better than numbers for this I fully agree and the
above would be a useful improvement. I have a quibble though;-)

I'm not sure that TA/CERT is the right distinction since both
trust anchors and pretty much everything else in PKIX are
represented by certificates. In pure PKIX terms, that'd maybe
be more like TA/EE (EE=end-entity), but I'm not sure if that
terminology would be useful or not for those less steeped in
PKIXishness.

S.

PS: no hats or anything, just a nitty comment.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 6 Aug 2013 15:30:50 +0200

> terminology would be useful or not for those less steeped in

Yes, {PKIX,DANE}-{TA,EE} would be better.

	jakob