Subject: [pkix] Updated Version of CAA

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 17:53:47 -0400

I have submitted an updated version of CAA.

http://www.ietf.org/id/draft-ietf-pkix-caa-01.txt

The main change here has been to take out most of the references to Relying
Party use except for:

1) The parts that explain why it is as bad idea for applications to use CAA
records intended to control issue to reject certs at the time of reliance.

2) Bit 6 is reserved to signify RP use (Bit 6 in DNS terms being Bit 1 to
everyone else).

Note that there is no statement to the effect of 'don't use this for relying
party use ever'. Nor is there any statement about how CAs might use the RP
bit to audit certificate issue.

Given that Google has deployed code that uses the 'auth' property for the
purpose of validating RP keys, I think that this is probably a good
separation to insist on in future. So we might want to state that the
policy/path properties are NEVER for use by RP applications.

I don't want to state that the RP bit should be ignored for issuer
properties, just that applications should not be using it. The value of the
RP bit in my view is for telling audit scripts that are set up to monitor
certificate issue that the site authorized the issuer in the past.

So for example, imagine that the EFF decides that it is going to use this
data in the EFF observatory. I want it to be possible for an auditor to
determine if a certificate that is inconsistent with the current issue
criteria is so because it was never consistent or because it might have been
at the time of issue but the criteria have changed since

Another issue from the list that has not been acted on in the text, but has
been acted on in my code is to support the specification of the issuer by
reference to a string rather than a policy OID.

I don't much like this proposal actually. Policy OIDs work very well for us
because they are hierarchical. They allow a customer to make statements like
'cert must be under Comodo.EV' or 'cert must be under Comodo'.

Policy OIDs are pretty well an objective definition, I don't think there are
many arguments in practice over who controls them. Certainly not in the Web
Trust or ETSI audit community. That is not necessarily true for an arbitrary
string.

Another disadvantage of strings is that they encourage variation and
ambiguity. There is precisely one way that my code will encode an OID. If we
start using strings then we have questions about "Comodo", "Comodo Group"
"Comodo Inc" "Comodo CA" which all have different meaning in a legal sense.
And then there is "Comodo" vs "Comodo " and "Comodo Inc" vs "Comodo Inc.".

I don't think strings work at all well.

The design of the RR may appear baroque, but it is designed to achieve
orthogonality. My objective was to make one request from the DNS world for
the purposes of CAA and not to need to go back again.

Getting a RR through the WG is one thing. Getting it into DNS servers is
quite another. I want to do that as infrequently as is possible.

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 16:53:44 -0700

On Jun 16, 2011, at 7:04 AM, Stephen Kent wrote:

> I think it best to remove the discussion of RP use of this feature, and focus instead on how CAs are expected to use it.

On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote:

> The main change here has been to take out most of the references to Relying Party use except for:
> 
> 1) The parts that explain why it is as bad idea for applications to use CAA records intended to control issue to reject certs at the time of reliance.
> 
> 2) Bit 6 is reserved to signify RP use (Bit 6 in DNS terms being Bit 1 to everyone else).

Taking out "most" is not what was asked for. The large amount of relying party text makes it sound like it should be used, the message to the list notwithstanding. 

> Note that there is no statement to the effect of 'don't use this for relying party use ever'. Nor is there any statement about how CAs might use the RP bit to audit certificate issue.

Noted. And thus the confusion.

> Given that Google has deployed code that uses the 'auth' property for the purpose of validating RP keys, I think that this is probably a good separation to insist on in future.

To the best of my understanding, that "deployed code" is not usable by nearly anyone, and is thus irrelevant.

>  So we might want to state that the policy/path properties are NEVER for use by RP applications. 

A better thing to do would be to do what was originally asked, and remove the discussion of RP use of CAA. In specific:

In section 1, remove:
   Relying Party  A party that makes use of an application whose
      operation depends on use of a Certificate for making a security
      decision.

   Relying Application  An application whose operation depends on use of
      a Certificate for making a security decision.

   Relying Party Authorization Set  The set of Authorization Entries for
      a domain name that are flagged for use by Relying Party
      Applications.  Analogous to an Access Control List but with no
      ordering specified.

In section 2, remove:
   Thus Relying Applications MUST NOT use failure
   to conform to currently published CAA records as a rejection criteria
   for certificates unless the published records are flagged as being
   intended for that use.

In section 2.1, remove:
      Relying Parties MUST NOT attempt to enforce CAA records if the
      Relying Party Authorization Set contains unknown property entry
      tags that are flagged as critical
. . .
      Relying Parties MUST NOT attempt to enforce CAA records if the
      Relying Party Authorization Set contains property entries with the
      Must Be Zero Tag Set.
. . .
   Relying Party  This bit is reserved to specify that the corresponding
      Property Entry MAY be used by Relying Party Applications.

      Relying Parties MUST NOT attempt to enforce properties specified
      in CAA records with the Relying Party bit set clear.
. . .
   Since the validity of an end entity certificate is typically a year
   or more it is quite possible that the CAA records published at a
   domain will change between the issue of the certificate and
   verification by a relying party.

In section 3.1, remove:
      Bit 6: Relying Application Use  If set, the property entry
         contains an Authorization Entry that forms part of the Relying
         Application Authorization Set for the corresponding domain.
Also change the example after the bit description to use bit 7 instead of bit 5.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 17:07:58 -0700

On Jul 7, 2011, at 2:53 PM, Phillip Hallam-Baker wrote:

> Another issue from the list that has not been acted on in the text, but has been acted on in my code is to support the specification of the issuer by reference to a string rather than a policy OID.
> 
> I don't much like this proposal actually. Policy OIDs work very well for us because they are hierarchical. They allow a customer to make statements like 'cert must be under Comodo.EV' or 'cert must be under Comodo'.

This is a good argument. Specifying a policy OID that is the root of the CA's policy OID arc without having to specify the exact-match OID seems like a good idea.

> Policy OIDs are pretty well an objective definition, I don't think there are many arguments in practice over who controls them. Certainly not in the Web Trust or ETSI audit community. That is not necessarily true for an arbitrary string.

The latter isn't a good argument. A site that publishes a CAA record is going to be as restrictive as it wants to be. The fact that a string like "Comodo" is not an objective definition isn't relevant: it is still good enough to make any CA whose name is not "Comodo" non-compliant if they issue a cert.

> Another disadvantage of strings is that they encourage variation and ambiguity. There is precisely one way that my code will encode an OID. If we start using strings then we have questions about "Comodo", "Comodo Group" "Comodo Inc" "Comodo CA" which all have different meaning in a legal sense. And then there is "Comodo" vs "Comodo " and "Comodo Inc" vs "Comodo Inc.".

Quite true. You would need to iteratively improve your code each time you were about to issue a cert but got a CAA record that your code did not recognize. However, that additional responsibility on the part of CAs is not of much concern to those of us in the domain-owning field.

> I don't think strings work at all well.

Strings as you portray them don't, particularly because they miss the advantage of OID trees. However, a better definition of strings might.

I propose that the identifier be a free-text string. If the string consists of only ASCII digits and ASCII periods, it is considered a policy OID, and that OID follows the rule that the policy property applies to the specified policy OID and all policy OIDs that fall within the same OID arc.

Using strings this proposed way also gets rid of the tortured ASN.1 OID encoding in the current draft. Now, it's just plain text, easily typed by the DNS admin.

Thoughts?

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 04:52:11 +0200 (MEST)

Paul Hoffman wrote:
> 
> Phillip Hallam-Baker wrote:
> >
> > If we start using strings then we have questions about "Comodo",
> > "Comodo Group" "Comodo Inc" "Comodo CA" which all have different
> > meaning in a legal sense. And then there is "Comodo" vs "Comodo "
> > and "Comodo Inc" vs "Comodo Inc.".

That is something that every CA can solve trivilally by
(a) choosing names for their businesses that humans can intuitively
recognize and (b) showing the information that admins will have to
enter in an easily accessible form on the CA's WebSite.
(But there are folks who like to rebrand businesses regularly,
 due to acquisition, merger, sale, consulting ...)

Rebranding a CA becomes difficult when there are several ten thousands
of customers with CAA records pointing to variantions of the current
brand.  If you force your customers to update those records,
some of them might put in the name of a different CA instead...

What strings are acceptable to a CA as CAA strings is something
that can be sufficiently addressed by documentation.

> Strings as you portray them don't, particularly because they miss the
> advantage of OID trees. However, a better definition of strings might.
> 
> I propose that the identifier be a free-text string. If the string
> consists of only ASCII digits and ASCII periods, it is considered a
> policy OID, and that OID follows the rule that the policy property
> applies to the specified policy OID and all policy OIDs that fall
> within the same OID arc.

If OIDs, then certainly the printable string form of OIDs
is preferable to binary blobs.

I personally think that OIDs are extremely tough on humans
(probably not when the entire universe contains only a one-digit number
 of them, but definitely when there are 100+ of them).

lower estimate for CA policy OIDs:
     3 policy oids  X  50 CAs  = 150 different OIDs

> 
> Using strings this proposed way also gets rid of the tortured ASN.1 OID
> encoding in the current draft. Now, it's just plain text, easily typed
> by the DNS admin.

I also think that the half million DNS admins and their perils are more
important than those 50 CAs (who do this for a living and can quickly
adapt to recognizing anything, because they do it daily).

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 8 Jul 2011 09:11:26 -0400

From: Paul Hoffman
> Strings as you portray them don't, particularly because
> they miss the advantage of OID trees. However, a better
> definition of strings might.
>
> I propose that the identifier be a free-text string.
> If the string consists of only ASCII digits and ASCII
> periods, it is considered a policy OID, and that OID
> follows the rule that the policy property applies to
> the specified policy OID and all policy OIDs that fall
> within the same OID arc.
>
> Using strings this proposed way also gets rid of the
> tortured ASN.1 OID encoding in the current draft.
> Now, it's just plain text, easily typed by the DNS admin.
>
> Thoughts?
>
> --Paul Hoffman

I think you meant the right thing but didn't say it clearly.  A string
encoding of an OID is fine, a free-text string is not. In order to avoid
the non-hierarchical and multi-variant nature of unconstrained strings
the rule should be:

   The string represents a policy OID and MUST consist of only
   ASCII digits and ASCII periods.

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jul 2011 07:15:04 -0700

>   ASCII digits and ASCII periods.

That was not my intended meaning: I really did mean "free text, and if that free text has this property, it is treated as an OID".

Given that this is a voluntary protocol that is being run by CAs, false negatives (that is, a CAA record that has an unrecognized text string from a domain that actually wanted a cert from the CA doing the test) seems fairly harmless. The fact that the CA can test the CAA record for a long period before issuance is needed mitigates any problem even further.

Why do you feel that free text ("WhizzyCA", "WhizzyCA, Inc.", "I want a WhizzyCA cert" ...) is not fine for this purpose? 

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 10:15:42 -0400

That risks getting into the problem that there are multiple encodings for
OIDs.

One solution would be to use the OID uri scheme:
http://tools.ietf.org/html/rfc3061

This would require a new property tag since we have deployed code.  We could
use 'issuer'

example:

example.com    CAA  33 issuer "oid:1.3.6.1.4.1"

On Fri, Jul 8, 2011 at 9:11 AM, Kemp, David P. <[email-masked]>wrote:

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

---

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

Phillip Hallam-Baker wrote:
> 
> That risks getting into the problem that there are multiple
> encodings for OIDs.

*cough*  What??

I've seen quite a variety of bugs around ASN.1,
but "multiple encodings for OIDs" is something I have never heard of.

I'm wondering: are printable string OIDs used in any SNMP-Tools?

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 10:25:25 -0400

No, I think that is broken.

It requires a mapping to be defined from the string to the policy for a
start.

One of the use cases we have is that public CAs frequently run CAs for other
parties under different policies or under variants of policies.

Another use case is to enable control of privately run CAs.

Management of those policies with OIDs or paths is straightforward.

Introducing a string such a WhizzyCA is much more complex and would lead at
least one CA to have a major commercial problem as they don't own the
principal brand under which they trade.

On Fri, Jul 8, 2011 at 10:15 AM, Paul Hoffman <[email-masked]> wrote:

> That was not my intended meaning: I really did mean "free text, and if that
> free text has this property, it is treated as an OID".
>
> Given that this is a voluntary protocol that is being run by CAs, false
> negatives (that is, a CAA record that has an unrecognized text string from a
> domain that actually wanted a cert from the CA doing the test) seems fairly
> harmless. The fact that the CA can test the CAA record for a long period
> before issuance is needed mitigates any problem even further.
>
> Why do you feel that free text ("WhizzyCA", "WhizzyCA, Inc.", "I want a
> WhizzyCA cert" ...) is not fine for this purpose?
>
> --Paul Hoffman
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 10:33:56 -0400

> I'm wondering: are printable string OIDs used in any SNMP-Tools?
There is one ASN.1 BER encoding of an OID

But there are multiple string encodings. You can add the text labels (as the
ITU spec says) or not (as is IETF practice).

That is why I was proposing to use the ASN.1 encoding.

Writing the code to encode and decode the asn.1 was the least of the
problems I had patching BIND. It is about 100 lines of C in total.

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Jul 2011 16:37:33 +0200 (MEST)

> It requires a mapping to be defined from the string to the policy for a

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.

> Management of those policies with OIDs or paths is straightforward.

No, it isn't.  Currently you do _not_ have to obtain/register an OID arc
to set up a private CA.  Yes, you can get one for free form the
IANA private enterprised registry, but IANA will not be happy if
it will have to process half a million requests for such OIDs
over the next couple of years, I assume.

Getting an OID arc from your national ISO-Member is no alternative.
13 years ago, the german DIN-Certco wanted to _lease_ OID arcs for
a yearly fee of around USD 6000,-...

> principal brand under which they trade.

Every CA cert MUST write an issuer name into all certs they issue
per rfc5280 (and likely some X.509 as well), so that the issue
you are claiming can not possibly exist.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 11:48:48 -0400

On Fri, Jul 8, 2011 at 10:37 AM, Martin Rex <[email-masked]> wrote:

> 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.

We can define other strings but that then starts to make audit impossible.

This is not an argument about human readability either. Until the DNS
servers have support for the CAA record, users are going to be entering the
RR as an unknown RR type which is going to be a string of hex digits.

Does the string 'VeriSign' mean VeriSign Class 3 or VeriSign EV? The issuer
name is the same in both cases. The industry already has a means to
distinguish those cases, its the policy oid.

I have no particular objection to adding an issuer property in addition. But
I do not think any commercial CA is going to want to use it.

> over the next couple of years, I assume.

That is why we put the path property in as an alternative.

The path property binds directly to a certificate on the cert path. In most
private CA cases that is going to be the self-signed root.

The advantage of that approach is that there is no ambiguity and no
registration required.

> a yearly fee of around USD 6000,-...

I very much doubt that they persisted in that delusion.

I don't see much value to having an OID there unless the CA in question is a
public CA. An OID is only going to be useful if there is a CPS etc.

For the type of use case you propose the path property is going to be much
easier to use.

A CA server that recognizes CAA is going to have a configuration tool that
spits out the appropriate CAA record in both the canonical and unknown
record formats.

The use I would see for CAA in such a context would be to control the range
of certificates that the server will issue for so that it cannot be used as
an attack vector against other sites.

Consider the case in which alice.edu has distributed its own private root to
browsers across the campus. They want to make it as easy as possible for
people to get certs. They don't want to allow people to register certs for
store.alice.edu which accepts Visa and Mastercard payments.

> you are claiming can not possibly exist.

No, that problem is addressed in existing contracts.

Use of that name in the context of CAA can only be addressed in future
contracts.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jul 2011 13:23:04 -0700

On Jul 8, 2011, at 7:15 AM, Phillip Hallam-Baker wrote:

> That risks getting into the problem that there are multiple encodings for OIDs.

Not really. Remember, it is the CA's software that is interpreting the information in the CAA record. The CA's software can be made to be flexible about what it recognizes as its own OID.

On Jul 8, 2011, at 7:25 AM, Phillip Hallam-Baker wrote:

> It requires a mapping to be defined from the string to the policy for a start. 

And what is the problem with that? Any CA can write software that makes such a mapping.

> One of the use cases we have is that public CAs frequently run CAs for other parties under different policies or under variants of policies.

Indeed. Why is that a problem? The master CA simply needs to recognize a larger number of strings. Adding strings to the checking program will take less tim than it will for you to respond to this message.

> Another use case is to enable control of privately run CAs. 

Absolutely. And that has the same answer.

> Management of those policies with OIDs or paths is straightforward. 

Fully agree. That's why I had a single, unambiguous rule for recognizing an OID in the string.

> Introducing a string such a WhizzyCA is much more complex and would lead at least one CA to have a major commercial problem as they don't own the principal brand under which they trade.

Huh? What on earth does "owning" a name have to do with the ability to see it in a string?

> it is the issuer name of the CA certificate

True, and irrelevant to matching one or more strings to a received CAA record.

> Should Comodo be using Comodo CA or UserTrust?

Either is fine.

> Should Symantec CA use Symantec, VeriSign or RSA Data Security?

Any of the three is fine.

> 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.
> 

If I were auditing Symantec's logs, and I saw instances where they issued certificates after seeing CAA records for "Symantec", "VeriSign", "RSA Data Security", "Symanteck", and so on, I would know what they used to accept certificates. I could simply ask them to justify each string. If I saw a CAA record for "Comodo", their justification for that might be a tad more difficult to swallow.

> This is not an argument about human readability either. Until the DNS servers have support for the CAA record, users are going to be entering the RR as an unknown RR type which is going to be a string of hex digits.

And the moment it is supported, that argument becomes bunk.

> Does the string 'VeriSign' mean VeriSign Class 3 or VeriSign EV? The issuer name is the same in both cases. The industry already has a means to distinguish those cases, its the policy oid.

True, and irrelevant. If Symantec issues a cert under either name, it is not a problem.

> I have no particular objection to adding an issuer property in addition. But I do not think any commercial CA is going to want to use it.

Fine: they don't have to.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jul 2011 16:34:05 -0400

>
>
> If I were auditing Symantec's logs, and I saw instances where they issued
> certificates after seeing CAA records for "Symantec", "VeriSign", "RSA Data
> Security", "Symanteck", and so on, I would know what they used to accept
> certificates. I could simply ask them to justify each string. If I saw a CAA
> record for "Comodo", their justification for that might be a tad more
> difficult to swallow.

So in short you want to turn my scheme which is deterministic into your
proposal that involves human interpretations and heuristics.

OK, I will put it in the draft as an option.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jul 2011 13:39:46 -0700

On Jul 8, 2011, at 1:34 PM, Phillip Hallam-Baker wrote:

> So in short you want to turn my scheme which is deterministic into your proposal that involves human interpretations and heuristics.

Correct. That is the same as Stephen Farrell proposed as well.

> OK, I will put it in the draft as an option.  

Thanks, but I was proposing that you replace your current complicated deterministic requirements with a simple string. A CA who only wants to accept a single deterministic string (the OID, encoded as ASCII digits and ASCII periods and nothing else) is free to do so.

Such a change would greatly shorten and simplify the protocol.

--Paul Hoffman

---

From: koichi sugimoto <[email-masked]>
Date: Mon, 11 Jul 2011 11:42:01 +0900

Hello Sirs,

The removal should be done directly or we especially for non-native
english speakers may confuse.
I agree with Paul.

Regards,
Koichi Sugimoto.