Subject: Re: [pkix] Policy OIDs in CAA

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 19:24:29 +0200 (MEST)

Phillip Hallam-Baker wrote:
> 
> Martin Rex <[email-masked]> wrote:
> 
> > Phillip Hallam-Baker wrote:
> > >
> > > It requires a mapping to be defined from the string to the policy for a
> > > start.
> >
> > CAs already have one such mapping, and once it is in productive use,
> > it becomes quite difficult to change -- even if the CA wants to,
> > it is the issuer name of the CA certificate
> 
> Should Comodo be using Comodo CA or UserTrust?
> 
> Should Symantec CA use Symantec, VeriSign or RSA Data Security?
> 
> Successful technology companies have an average lifespan of 5-10 years
> (unsuccessful ones can have the same lifespan measured in months). Names
> change, ownership changes, roles change.
> 
> The name that is in the root cert is frequently one that we would wish the
> user see as little as possible.

I'm sorry. but I strongly disagree.

It MUST remain possible to the admins and to the consumers to
configure their trust anchors manually, and therefore the names
in those certs WILL be inevitably visible to the users.

Trying to refer to trust anchors with some weird policy IDs,
potentially ones that are not even part of the CA certs
contained in configurations of the installed base, seems like
a bad idea and a very undesirable usability problem.

I believe CAA ought to work with an existing attribute of the
CA certs in the installed base that is prominently visible
in trust anchors management UIs of the currently installed base.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 13:28:38 -0400

Policy OIDs are an existing cert attribute that is visible in the UI.

We can add an issuer property if you think it is going to be helpful.

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 20:25:49 +0200 (MEST)

> We can add an issuer property if you think it is going to be helpful.

Let's see:  https://www.comodo.com/

Firefox 3.5:
  TA: AddTrust External CA Root   _NO_ policy
    \____  COMODO Certification Autority   2.5.29.32.anyPolicy(0)
     \____ COMODO Extended Validation Secure Server CA  2.5.29.32.anyPolicy(0)
      \___ www.comodo.com     1.3.6.1.4.1.6449.1.2.1.5.1

Firefox 3.6:
  TA: COMODO Certification Autority    _NO_ policy
    \___ COMODO Extended Validation Secure Server CA  2.5.29.32.anyPolicy(0)
     \___ www.comodo.com     1.3.6.1.4.1.6449.1.2.1.5.1
    
I somehow fail to see any policy OIDs in any of Comodo's CA certs that
could be used to identify these certs as issuers through CAA.

CAA is something between the DNS Admin and the CA, and I had assumed
you wanted it to become usable _soon_.  So you ought to try something
that works well with the existing UIs and the existing CA certs.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 14:53:35 -0400

Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ?

---

From: Martin Rex <[email-masked]>
Date: Sat, 9 Jul 2011 00:14:09 +0200 (MEST)

> Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ?

I does not appear in any of the Comodo CA certificates.

The most logical and most usable choice for the DNS admin would be an
**existing** attribute of any CA certificate along the path to the
trust anchor.

So that when I want to configure a TLS client to be able to authenticate
servers in that domain, I can easily determine the CA certificate(s)
that I need to add to my trust anchor store.

-Martin

> --001636c92664cd701b04a793593e
> Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Whats wrong with=A0<span class=3D"Apple-style-span" style=3D"border-collaps=
> e: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; font-s=
> ize: 16px; ">1.3.6.1.4.1.6449.1.2.1.5.1 ?</span><div><font class=3D"Apple-s=
> tyle-span" color=3D"#333333" face=3D"arial, sans-serif"><span class=3D"Appl=
> e-style-span" style=3D"border-collapse: collapse; font-size: 16px;"><br>
> </span></font></div><div><br><div class=3D"gmail_quote">On Fri, Jul 8, 2011=
>  at 2:25 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
> m">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
> style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> <div class=3D"im">Phillip Hallam-Baker wrote:<br>
> &gt;<br>
> &gt; Policy OIDs are an existing cert attribute that is visible in the UI.<=
> br>
> &gt;<br>
> &gt; We can add an issuer property if you think it is going to be helpful.<=
> br>
> <br>
> </div>Let&#39;s see: =A0<a href=3D"https://www.comodo.com/" target=3D"_blan=
> k">https://www.comodo.com/</a><br>
> <br>
> Firefox 3.5:<br>
>  =A0TA: AddTrust External CA Root =A0 _NO_ policy<br>
>  =A0 =A0\____ =A0COMODO Certification Autority =A0 2.5.29.32.anyPolicy(0)<b=
> r>
>  =A0 =A0 \____ COMODO Extended Validation Secure Server CA =A02.5.29.32.any=
> Policy(0)<br>
>  =A0 =A0 =A0\___ <a href=3D"http://www.comodo.com" target=3D"_blank">www.co=
> modo.com</a> =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1<br>
> <br>
> Firefox 3.6:<br>
>  =A0TA: COMODO Certification Autority =A0 =A0_NO_ policy<br>
>  =A0 =A0\___ COMODO Extended Validation Secure Server CA =A02.5.29.32.anyPo=
> licy(0)<br>
>  =A0 =A0 \___ <a href=3D"http://www.comodo.com" target=3D"_blank">www.comod=
> o.com</a> =A0 =A0 1.3.6.1.4.1.6449.1.2.1.5.1<br>
> <br>
> I somehow fail to see any policy OIDs in any of Comodo&#39;s CA certs that<=
> br>
> could be used to identify these certs as issuers through CAA.<br>
> <br>
> <br>
> CAA is something between the DNS Admin and the CA, and I had assumed<br>
> you wanted it to become usable _soon_. =A0So you ought to try something<br>
> that works well with the existing UIs and the existing CA certs.<br>
> <font color=3D"#888888"><br>
> <br>
> -Martin<br>
> <br>
> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
> =3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
> </div>
> 
> --001636c92664cd701b04a793593e--
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 18:37:47 -0400

On Fri, Jul 8, 2011 at 6:14 PM, Martin Rex <[email-masked]> wrote:

> I does not appear in any of the Comodo CA certificates
>

It does not have to, that is how X.509 works.

The CA specifies the end entity certificate policy in the end entity
certificate. That is how it has always worked.

> **existing** attribute of any CA certificate along the path to the

No, I think it would be a string proposed by the CA on their Web site.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 09 Jul 2011 17:43:17 +1200

>Whats wrong with 1.3.6.1.4.1.6449.1.2.1.5.1 ?

Nothing wrong with it, but what is it?  So many of Comodo's OIDs are
undocumented (or at least not documented anywhere that Google can find them)
that they're essentially useless in telling you anything about the cert
they're in.

(This isn't just a Comodo problem, it exists across all CAs, which is why I've
made this a public reply).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 9 Jul 2011 09:22:58 +0300

> made this a public reply).

To use this in CAA, a domain owner would have to know in advance what OID the CA was going to stick in the certificate. Is this public knowledge?

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 09 Jul 2011 20:09:32 +1200

Yoav Nir <[email-masked]> writes:

>To use this in CAA, a domain owner would have to know in advance what OID the
>CA was going to stick in the certificate. Is this public knowledge?

Nope, and the problem of completely undocumented policy OIDs that RPs are
supposed to use to make decisions is systemic throughout CA-issued certs.

(CC'd to the Mozilla policy list, which is probably a better place for this. 
There should be a requirement that CAs accepted by Mozilla and other browsers 
publicly document all OIDs they use in certs in an easily-accessible manner, 
either via a central registry administered by Mozilla or a flat text file or 
web page on the CA site).

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 9 Jul 2011 12:48:44 -0400

The CA is going to have to direct the user s to what information to put in
the record anyway.

And the user is not going to know what their cert chain looks like before
the cert is issued.

The criteria I see for the format of the CAA parameter value (in order of
importance) are

1) Unambiguity: Can there be a dispute as to the right of the CA to issue
under the parameter value.

2) Granularity: Can a the domain owner specify the issue constraints with
precision, e.g. Alice CA EV only

3) Stability: Does the parameter value need to be updated in response to
changes at the CA

4) Obtainability: Is it easy to obtain the necessary code points?

5) Readability: Is it easy for a human reader to interpret the data without
recourse to external data sources?

The scores I have are

Policy: Meets all except 5
Path: Meets all except 3, 5
Issuer: Meets 4, 5

Path is interesting in that it breaks in a particular circumstance where
people might want it to break.

---

From: Ian G <[email-masked]>
Date: Sun, 10 Jul 2011 08:48:43 +1000

On 9/07/11 6:09 PM, Peter Gutmann wrote:
> Yoav Nir<[email-masked]>  writes:
>

:)

> web page on the CA site).

Good luck on that one.  I've no idea how you get any RP excitement with 
an OID.  It seems to be a bona fide breach of Kherkhoffs' 6th.

EVG has an OID of some form, but it is interpreted by software, so in 
this case, RP-proxy role of Mozilla.

iang