Subject: [dane] Making certificate usage type 2 "CA-only"?

From: Ondrej Mikle <[email-masked]>
Date: Thu, 08 Mar 2012 17:16:07 +0100

Hi all,

as there was some confusion in the last "I-D Action:
draft-ietf-dane-protocol-17.txt" thread about certificate usage 2, maybe
it would be clearer to restrict usage 2 only to CA-certificates?

Since we created usage type 3, it could be nice to have
"disjunct/orthogonal" certificate usage types. ATM certificate usage 2
can be used for CA-cert as well as EE-cert and thus overlaps a bit with
certificate usage 3. I think that usage type 2 is intended for CA certs.

It would require following minor modifications in draft:

- in section 2.1.1 usage 2, change "certificate" to "CA certificate" on
the first line, so it'd become:

      2 -- Certificate usage 2 is used to specify a CA certificate, or
      the public key of such a certificate, that must be used as a trust

- in section A.1, the last paragraph starting with "Certificate usage 2
[...]" would become:

   Certificate usage 2 might be affected by the different types of
   validation path building as well.

- in section B.2, the pseudocode dealing with certificate usage 2 would
become (basically almost identical to usage 0 except the "that has R as
the trust anchor" part):

     // pass PKIX certificate validation using TLSA record as the
     //    trust anchor
     if (R.certUsage == 2) {
       for each PKIX certification path H that has R as the
           trust anchor {
         if (C passes PKIX certification path validation in H) {
           for each D in H {
             if ((D is a CA certificate) and
                 Match(R.matchingType, Select(R.selectorType, D),
                       R.cert)) {
               Finish(ACCEPT)
             }
           }
         }
       }
     }

BTW I've just noticed that current pseudocode in case of usage 2 only
tests against the end-entity certificate C, not against every cert in
validation path.

Ondrej Mikle

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 9 Mar 2012 11:47:50 +0100

Hi WG,

could you please respond to this.  I think it's a reasonable suggestion,
because now Type 2 and Type 3 overlap, but it might have a big impact on
the protocol, so it needs at least some thinking how it will affect the
protocol.

O.

On 8. 3. 2012, at 17:16, Ondrej Mikle wrote:

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

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 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: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Mar 2012 09:32:06 -0800

I am strongly in favor of doing something so that the cases are clearly distinguishable.

I think it might be more a case of one-certificate chain vs > one certificate in chain as text for distinguishing.

Jim
]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Friday, March 09, 2012 2:48 AM
> To: IETF DANE WG list
> Subject: Re: [dane] Making certificate usage type 2 "CA-only"?
> 
> Hi WG,
> 
> because now Type 2 and Type 3 overlap, but it might have a big impact on the
> protocol, so it needs at least some thinking how it will affect the protocol.
> 
> O.
> 
> > draft-ietf-dane-protocol-17.txt" thread about certificate usage 2,
> > maybe it would be clearer to restrict usage 2 only to CA-certificates?
> >
> > can be used for CA-cert as well as EE-cert and thus overlaps a bit
> > with certificate usage 3. I think that usage type 2 is intended for CA certs.
> >
> >
> > - in section 2.1.1 usage 2, change "certificate" to "CA certificate"
> > on the first line, so it'd become:
> >
> > - in section A.1, the last paragraph starting with "Certificate usage
> > 2 [...]" would become:
> >
> > - in section B.2, the pseudocode dealing with certificate usage 2
> > would become (basically almost identical to usage 0 except the "that
> > has R as the trust anchor" part):
> >
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: James Cloos <[email-masked]>
Date: Fri, 09 Mar 2012 16:34:16 -0500

>>>>> "OS" == Ondřej Surý <[email-masked]> writes:

OS> could you please respond to this.  I think it's a reasonable suggestion,
OS> because now Type 2 and Type 3 overlap, but it might have a big impact on
OS> the protocol, so it needs at least some thinking how it will affect the
OS> protocol.

Given the addition of type 3, it is reasonable to restrict type 2 from
applying to an EE cert.

But it still should be possible to list either a root cert or an
intermediate cert in a type 2 RR.

I'm too exhausted right not to suggest prose for that.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sat, 10 Mar 2012 09:59:34 -0500

> intermediate cert in a type 2 RR.

Asserting a trust anchor makes this true trivially, since path validation stops when you hit a trust actor, even if it's in the middle of a provided chain.

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 10 Mar 2012 07:39:29 -0800

It would *really* help Jakob and I if people who have opinions would also post proposed text changes. I suspect it will help other people in the WG as well...

--Paul Hoffman

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 12 Mar 2012 11:54:22 +0100

On 03/10/2012 04:39 PM, Paul Hoffman wrote:
> It would *really* help Jakob and I if people who have opinions
> would also post proposed text changes. I suspect it will help other
> people in the WG as well...
> 
This is what I understand from the text:

Usetype 2.  cert is trusted.  PKIX path validation MUST be done. cert
MAY be root-CA, intermediate-CA, EE-cert.

Usetype 3.  cert is trusted. PKIX path validation MUST NOT be done.
cert MUST be the EE-cert.

Thus, PKIX constraints on the cert in type 2.  No PKIX constraints on
the cert in type 3?  (I mean the checks: if you do PKIX path
validation with one certificate whose key is trusted, then there are
still a number of additional checks, those checks I mean here.)

If you use public keys, it is the same, from security perspective.

Rereading, I am unsure if usetype 2, the PKIX Path MUST contain the
cert from TLSA, or if it MAY contain the cert from TLSA.  (usetype 1
is CA-constraint, this one 'adds a trust anchor you may not have'; so
I think it 'may', but then 'a' was changed to 'the' in this text).

So, this is a table with the spectrum of possibilities here (sorry for
ascii art)

header:  Certis    DoPKIXPath   pathvalidation   certMUST
header2  pkixTA    validation   mustcontaincert  equalEE

usetype0:  no      yes            yes            no
usetype1:  no      yes            no             yes
usetype2:  yes     yes            no             no
usetype3:  no      no             no             yes

short comments on rows:
usetype0: constrain CA-given (root/intermediate/EE) to X.
usetype1: constrain CA-given EE to X
usetype2: add trust-anchor X, do PKIX-validation.
usetype3: fix EE to X, no PKIX stuff.

short comments on columns:
certisPKIXTA: does TLSA cert add a new PKIX trust anchor?
DoPKIXPathvalidation: if the PKIX path validation must be passed.
pathvalidationmustcontaincert: the valid pkix path must contain the
TLSA cert.  If no, this means pkix must load the trusted CAs list.
certMUSTequalEE: TLSA must match EE.

Best regards,
   Wouter

---

From: Ondrej Mikle <[email-masked]>
Date: Mon, 12 Mar 2012 12:43:25 +0100

> I think it 'may', but then 'a' was changed to 'the' in this text).

You're right, for usage type 2 the text does not specify whether the
cert from TLSA MUST be in validation path (neither do older revisions
like -17 and -16). Or possibly it's somehow implied (though I don't see
how).

So far I've understood it that it is required. Without the requirement
of having the cert from TLSA in validation chain for usage 2 it would
just add a TA, but wouldn't provide any constraint (meaning arbitrary
PKIX-validated chain would be accepted).

Thus I propose adding one sentence to section 2.1.1, at the end of
paragraph covering "2 -- Certificate usage 2":

"Certificate from TLSA record must be present in validation path in
order for such association to succeed."

Looking back at pseudocode in section B.2 from revision -14 I think
that's how it was originally intended - part for usage type 2 reads "for
each PKIX validation chain H that has R as the trust anchor".

> header2  pkixTA    validation   mustcontaincert  equalEE

So in the table above "pathvalidation mustcontaincert" would have "yes"
for "usetype2".

I'd also argue that "pathvalidation mustcontaincert" should be "yes" for
"usetype1" (such EE cert must be part of validation path).

Ondrej

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Mar 2012 02:57:19 +0100 (MET)

> header2  pkixTA    validation   mustcontaincert  equalEE

  usetype3:  no      no             no             DON'T CARE

There should *NOT* be any change on the certificate about whether
it looks like an EE cert or not for usatype3.  It could be
an X.509v1 self-signed cert, and X.509v3 cert with BasicConstraints cA=TRUE
or an X.509v3 cert with BasicConstraints cA=FALSE -- all of these are
in widespread use (and which one is created depends on the PKI toolkit).

-Martin