Re: [dane] On the PKIX-TA / PKIX-CA question… [ One week WGLC ]

[Bry8 Star <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

U = Usage
DANE = TLSA
PKIX = PKIX certification path validation (CPV)
EE = End entity.

That <something> can be DOI or ZOI (Domain/Zone Owner Issued) ? ?
or DI / ZI  (Domain/Zone Issued).

This 4 U categories are not enough, as "The Certificate Usage Field"
(Section 2.1.1 of RFC 6698).

*Please add* at least few more appropriate category for declaring
very accurately & correctly, so that no confusion exists, for
publicly declaring to others: (A) INTERMEDIATE CA or TA certs (under
U=0 & U=2), (B) a category for EE certs with PKIX *AND* DANE check
under TA (U=2) certs (if U=1 is not for that purpose).

Joining suggestion from this thread:
0 - "CA constraint" = CA-CHECK = PKIX-CA = LIMIT-CA = REQUIRED-CA
    = CA-LOVER
1 - "service certificate constraint" = EE-CHECK = LIMIT-EE
    = REQUIRED-LEAF = CA-SLAVE
2 - "trust anchor assertion" = DANE-TA = PKIX-TA = TRUSTED-CA = CA-OWNER
3 - "domain-issued certificate" = DANE-EE = MATCHING-LEAF = CA-HATER

U = 0 can be used for either a TA or CA cert declaration.
U = 2 is for Domain-issued TA cert declaration.
U = 3 is for Domain-issued EE cert declaration.

TLSA = DANE

So these seems to be appropriate from my point of view for now:
0 = 3PI-CA:TLSA+PKIX  (for 3rd Party Issued CA or TA cert)
  or 3PI-TA
1 = EE:TLSA+PKIX  (for End entity cert)
2 = DOI-TA:TLSA+PKIX  (for Domain Owner Issued TA cert)
  or ZOI-TA  (for Zone Owner Issued TA cert)
3 = DOI-EE:TLSA+NO-PKIX (for Domain Owner Issued EE cert)
  or ZOI-EE

TLSA = DANE

U = 1 type of SSL cert declaration, (are PKIX+TLSA *checked*),
and 1 can be:
either under the U = 0 (are also PKIX+DANE *checked*) cert,
or can be under the U = 2 (are PKIX+DANE *checked*) cert.

Since U = 3 DO *NOT* REQUIRE a PKIX CPV check,
then, *WHERE* is the EE-DANE+PKIX-CHECKED category !? for declaring
certs that are under U=2 ?

So, can U = 1 type cert TLSA(DANE) declaration, be used for such
certs, which can be either under a CA (U=0) or under a TA (U=2), to
me this seems to make sense.
Then U=1 can serve EE_DANE+PKIX_CHECKED, for both U=0 & U=2.

BrS



Received from Warren Kumari, on 2013-12-02 10:44 AM:
> Hi all,
> 
> So, it seems that I judged consensus without enough data. I should know by now that naming things is always a fun topic :-)
> 
> So, lets try and get this "what to call it" question nailed down once and for all.
> 
> Please express a preference for:
> 
> PKIX-TA
> PKIX-CA
> DANE-<something>
> 
> I don't think that anyone really *loves* any of the above, so an even better outcome is that someone proposes a better acronym that everyone likes...
> 
> We are keeping this to 1 week -- please get a response in before Monday, Dec 9th.
> 
> W
> 



Reference, from RFC 6698:

Hoffman & Schlyter           Standards Track                    [Page 7]
RFC 6698            DNS-Based Authentication for TLS         August 2012

0 -- Certificate usage 0 is used to specify a CA certificate, or
  the public key of such a certificate, that MUST be found in any of
  the PKIX certification paths for the end entity certificate given
  by the server in TLS.  This certificate usage is sometimes
  referred to as "CA constraint" because it limits which CA can be
  used to issue certificates for a given service on a host.  The
  presented certificate MUST pass PKIX certification path
  validation, and a CA certificate that matches the TLSA record MUST
  be included as part of a valid certification path.  Because this
  certificate usage allows both trust anchors and CA certificates,
  the certificate might or might not have the basicConstraints
  extension present.

1 -- Certificate usage 1 is used to specify an end entity
  certificate, or the public key of such a certificate, that MUST be
  matched with the end entity certificate given by the server in
  TLS.  This certificate usage is sometimes referred to as "service
  certificate constraint" because it limits which end entity
  certificate can be used by a given service on a host.  The target
  certificate MUST pass PKIX certification path validation and MUST
  match the TLSA record.

2 -- Certificate usage 2 is used to specify a certificate, or the
  public key of such a certificate, that MUST be used as the trust
  anchor when validating the end entity certificate given by the
  server in TLS.  This certificate usage is sometimes referred to as
  "trust anchor assertion" and allows a domain name administrator to
  specify a new trust anchor -- for example, if the domain issues
  its own certificates under its own CA that is not expected to be
  in the end users' collection of trust anchors.  The target
  certificate MUST pass PKIX certification path validation, with any
  certificate matching the TLSA record considered to be a trust
  anchor for this certification path validation.

3 -- Certificate usage 3 is used to specify a certificate, or the
  public key of such a certificate, that MUST match the end entity
  certificate given by the server in TLS.  This certificate usage is
  sometimes referred to as "domain-issued certificate" because it
  allows for a domain name administrator to issue certificates for a
  domain without involving a third-party CA.  The target certificate
  MUST match the TLSA record.  The difference between certificate
  usage 1 and certificate usage 3 is that certificate usage 1
  requires that the certificate pass PKIX validation, but PKIX
  validation is not tested for certificate usage 3.

Note: Pls make sure to reply only into one email
      address: [e-mail] , when you reply, Thanks in advance.
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJSnr8SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDNzBGRDNEMDcwRUI1Q0FERkMwNDBGQ0I4
MEY2OEE0NjFGNTkyM0ZBAAoJEID2ikYfWSP6O3oP/0e6+6BPo2FsASnXLgdcbp08
qc2GHTH6brZ4S/qAswgj/VIJRE/1/SFQhZHAtRlRz96GIoZZ1g9WrIjsXt4qsmto
74jJqC9Ay3fa2dj9qVJZSpLcImDtnVoZIvaXkfCDS6afU3anTa5KjUFoNS3PRHjg
KX1eiNzP+4r1phf+gQNv8OOxRM54/FHvmfx5f0T34Ac9bv80NHNUNZR1VpsGCxBB
uKVB+gIF6Pnt/RP+XN9wAdT7cOPmPdNIVN39ebqsgt3MGL694otr3rUlczSD+OcD
tpAv+uEhdXUQN5RZt9z2cwxxh3V6iM1vQhoHRA3eHYgkrB3TOhKwmJRNuDREAVnd
kLXn6fLei+asvauVlyFYACjmdk8tTPJ1wCDb3FumbYOZ3u8guXuAfLOJdJYGLbSP
c2RKu0GJq9DtIxQqTKIHz32Tydf3VccAy2e/C9IxuHcfiVqbq6rTE1kYxbci6zv9
1EvFH+QKVRiZg2OzGFmLqu0tzD/QGsIjTBVpvIc2CVru52RsmzSGDxLaFsozf7PS
kAkQN1q44PGUstixajhtpE9BYQ3ZiyTrG5LSciG8yzLNbSmajFm29GSs//GU60SB
zLTt7JNJnvmoHzVfVCE1LkoMw/zve+xdvStwIuo47fCOV/AHntxJ+hI0rRLK/Bbr
nQvVKM+49opvJY9Bdzwj
=rwXE
-----END PGP SIGNATURE-----