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.
> 
> Value         Short Description       Reference
> 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>]
> 
> 
> 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 <http://www.iana.org/go/rfc6698>]
> 1     SubjectPublicKeyInfo    [RFC6698 <http://www.iana.org/go/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
> 
> 
> 
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
> 

Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to