Subject: [pkix] Fwd: [Gen-art] Gen-ART review of draft-ietf-pkix-caa-10

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 8 Jul 2012 21:22:35 -0400

FYI, my comments on CAA.

Begin forwarded message:

> From: "Richard L. Barnes" <[email-masked]>
> Subject: [Gen-art] Gen-ART review of draft-ietf-pkix-caa-10
> Date: July 6, 2012 5:44:06 PM EDT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you may
> receive.
> 
> Document: draft-ietf-pkix-caa-10
> Reviewer: Richard Barnes
> Review Date: 06-July-2012
> IETF LC End Date: 17-July-2012
> IESG Telechat date: TBD
> 
> Summary: Nearly ready, but has a couple of major issues, and would benefit from several clarifications
> 
> MAJOR:
> 
> General: Why not DANE?
> It would help prevent confusion if this document could differentiate itself a little more clearly from the DANE/TLSA specifications, especially since the RRs have largely the same information content.  It seems to me that there are a few main reasons:
> -- Authorization without exclusion.  A domain holder might wish to authorize an issuer to issue a certificate without invalidating any other certificates that it has deployed.
> -- Avoiding confusion: Having a different RRtype helps avoid these authorizations being confused with DANE records by relying parties.
> -- Incident reporting via the "iodef" type.
> 
> General: Tree walking
> The tree walking algorithm specified in Section 3 seems like a really bad idea.  It saves the domain holder from having to deploy separate CAA records for every subdomain, but has some tricky consequences.  For example, because the algorithm stops at the first CAA it finds, authorizations don't flow all the way down the tree, just to the first CAA point, where they get replaced.  Likewise, if a domain holder doesn't agree with a parent domain's CAAs for his domain, he's forced to deploy a null CAA defensively.  Recommend removing the tree walking / Extended Issuer Authorization Set.
> 
> General: Public Delegation Points
> The concept of a Public Delegation Point seems unhelpful here, because it is not well-defined.  
> 
> Section 5.4. "... civil or criminal sanctions."
> This is complete speculation, and highly contingent on legal matters that don't belong in a technical specification.  Suggested cutting this sentence off:
> "It is thus unlikely that the attack would succeed."
> 
> 
> MINOR:
> 
> Section 2. "CAA records MAY be used by Certificate Evaluators..."
> This recommendation seems to contradict the sentence immediately preceding.  From the perspective of deciding whether a certificate is valid, a Certificate Evaluator is the same as a Relying Party, so if RPs shouldn't use CAA, then neither should Certificate Evaluators.  (In general, the concept of a Certificate Evaluator seems unhelpful and confusing; I would suggest just using RP, if anything.)
> 
> Section 2.1. "express written authority"
> Requiring "written" authority seems like it goes beyond the scope of a technical specification.
> 
> Section 4.1.1. "ASCII letter and numbers in lower case."
> Is there any particular reason that this has to be lower case?  It might be helpful to specify ABNF for it, e.g.:
>  tag = 1*(ALPHA/DIGIT)
> 
> Section 4.2. ABNF
> This section should specify that IDNs MUST be represented in A-label form, with a reference to RFC 5890.
> 
> Section 4.2. "This form of issue restriction..."
> It would be helpful to explain this a little more fully.  The major point of a "null CAA" record seems to (1) stop the tree-climbing in the CA processing, and (2) let CAs know that the domain owner understands CAA.  If the tree-climbing is removed (as suggested above), then is there really value in this beyond having no CAA at all?  (If not, then just make the "[domain]" above into "domain".)
> 
> Section 5.1. 
> It would be helpful to have a pointer to DANE here.
> 
> 
> EDITORIAL:
> 
> Section 2. "issueance" -> "issuance" 
> 
> Section 2. "Certificate Policy Statement" 
> Seems like "Certification Practices Statement" would be more appropriate here.
> 
> Section 2.1. "a Web service"
> It would be helpful to have a reference to RFC 6546 at this point, instead of all the way at the end.
> 
> Section 3. Bullets
> It would be helpful to describe the process for assembling the Extended Issuer Authorization Set.  Namely, something like the following:
> 1. Check for CAA records under the target domain name.  
> 2. If they exist, then they are the EIAS.
> 3. Otherwise, remove a label from the name
> 4. If the name is now empty (the root), then the EIAS is empty
> 5. Otherwise go to step (1) with the new domain name
> 
> Section 5. "Observance of CAA records by issuers is subject to accountability controls."
> This is obviously not true as written;even after this RFC is published, not every CA will have controls enforced on it.  Suggested text:
> "An issuer's practices with regard to CAA records can be made subject to accountability  controls."
> In a similar vein, further down, "Since  CA could have avoided ... is increased."  It doesn't seem useful to speculate on probability, but the possibility is good to point out.  Suggested text for this and the following sentence:
> "Since CAs can have avoided the mis-issue by performing CAA processing, if a particular CA does not use CAA, it could cause other entities to regard it as less trustworthy.  For example, failure to observe CAA issue restrictions might be used as an objective criterion for excluding issuers from embedded trust anchor lists."
> 
> Section 5. "negligent CAs will likely increase" -> "negligent CAs may increase"
> 
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Jul 2012 11:48:38 -0400

There are quite a few comments here, some I think can be taken as
editorial, others are more substantial.

>> It would help prevent confusion if this document could differentiate itself a little more clearly from the DANE/TLSA specifications, especially since the RRs have largely the same information cont…

The use cases and action are entirely disjoint. DANE is attempting to
establish a new method of key distribution and specifies steps to be
taken in the client to verify keys. CAA specifies steps to be taken by
issuers to validate subjects.

I can write a mention in the preamble. I was avoiding doing that when
DANE was a draft as having two drafts cross reference when not
essential is usually a bad idea.

>> -- Incident reporting via the "iodef" type.

I think the more obvious one being that DANE records make statements
about certificates and CAA is about what happens before a certificate
is created.

>> The tree walking algorithm specified in Section 3 seems like a really bad idea.  It saves the domain holder from having to deploy separate CAA records for every subdomain, but has some tricky cons…

We went through this on the list. Originally there was no tree
walking, only the leaf node and public delegation point were looked
at. This was changed to being the whole length of the tree because it
is only being done at time of issue of a cert. I think this makes best
sense.

The assumption is that a DNS domain superior node has the capability
to enforce as much control as it likes on subordinate nodes. Therefore
any delegation of control is a matter of choice and should be assumed
is done because the superior node wants to delegate that control.

Since CAA authorizations are additive, this is the only way that
allows the use cases to be met. There is a need to carve out
exceptions when a subdomain is being delegated to another party such
as an outsourced mail provider.

Without any form of climbing, the spec is broken as an attacker can
request a certificate for bogus.paypal.com and evade the CAA checks
completely.

>> The concept of a Public Delegation Point seems unhelpful here, because it is not well-defined.

CAs are already required to manage lists of public delegation points
to ensure that certificates are properly issued. It is a fuzzy concept
because of the way DNS has evolved and in particular the way certain
TLDs like .uk are structured.

>> "It is thus unlikely that the attack would succeed."

No, knowingly making an untrue statement to obtain a valuable
consideration is fraud under UK, US and pretty much any other legal
system. An audit statement is quite obviously a valuable
consideration.

I don't see that there is any speculation there. I will ask the
CABForum folk for an opinion. We have no shortage of lawyers.

>> This recommendation seems to contradict the sentence immediately preceding.  From the perspective of deciding whether a certificate is valid, a Certificate Evaluator is the same as a Relying Party…

The circumstances are entirely different.

It is assumed that a client only has direct access to the DNS which
only holds current statements about the DNS and can only make a go/no
go decision. I don't think that you are going to find any DNS
information suitable for a go/no go decision.

A certificate evaluator is going to be taking information from a wide
variety of sources and make use of archival series. If it has been
sampling the CAA records of a domain on a daily basis for 5 years it
can make decisions that are rather more robust. But even then I would
not want to rely on the DNS information alone, I would tie in
information from checking the Web site, IP blacklists and the like.

CAA records are intelligence, but they are not directly actionable
without other data.

>> Requiring "written" authority seems like it goes beyond the scope of a technical specification.

Written authority means authority expressed in a fixed medium that can
be produced on demand. That seems like a necessary requirement if the
accountability control is going to mean anything. Written does not
have to be written on paper, emails are written but they do have to be
fixed.

I don't think we want to allow someone to claim that they were
authorized to issue for Comodo or Symantec on the basis of a phone
call or a chat session.

>> Is there any particular reason that this has to be lower case?  It might be helpful to specify ABNF for it, e.g.:

There is no particular reason to use upper case. Mandating registry
tags be lower case is a low cost way to avoid ambiguity and confusion
down the line.

>> This section should specify that IDNs MUST be represented in A-label form, with a reference to RFC 5890.

OK, will do that.

>> It would be helpful to explain this a little more fully.  The major point of a "null CAA" record seems to (1) stop the tree-climbing in the CA processing, and (2) let CAs know that the domain owne…

We have a very good reason for requiring climbing.

>> It would be helpful to have a pointer to DANE here.

Umm. I am willing to do that now its in the RFC editor queue.

>> Seems like "Certification Practices Statement" would be more appropriate here.

No, there is a difference between the two and I am very clear on which
one is being specified.

A policy statement sets out criteria that the practices must meet. A
relying party should only rely on the undertakings set out in the
policy. The practices statement specifies how the policy is met and is
principally a document for the auditors to work against.

>> It would be helpful to have a reference to RFC 6546 at this point, instead of all the way at the end.

OK

>> "An issuer's practices with regard to CAA records can be made subject to accountability  controls."

I think it is a MAY.

The criteria here will come from CABForum but I don't want to tie this
draft to one particular body as there may be others.

>> "Since CAs can have avoided the mis-issue by performing CAA processing, if a particular CA does not use CAA, it could cause other entities to regard it as less trustworthy.  For example, failure t…

OK

>> Section 5. "negligent CAs will likely increase" -> "negligent CAs may increase"

OK

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 10 Jul 2012 14:30:03 -0400

Areas of agreement trimmed; responses inline. 

> is only being done at time of issue of a cert. I think this makes best

Was the possibility of looking only at the leaf node discussed?  It seems like if you're requesting a cert for a domain, you should be authorized to provision a record for that domain, so walking up the tree is really just an optimization.

> request a certificate for bogus.paypal.com and evade the CAA checks

OK, I think I understand this better now.  As I understand the scenario, you mean:
1. paypal.com provisions CAA 0 issue ";"
2. Attacker who cannot control bogus.paypal.com asks for a cert
3. CA finds nothing under bogus.paypal.com, but finds ";" CAA under paypal.com
4. Because (1) there is a CAA record, and (2) issuing would not match a CAA record, the CA MUST NOT issue.

The crux of this seems to be that provisioning a null issuer (";") conveys a different policy than having no CAA record at all.  That was not apparent to me from reading the text, so it might be something helpful to call out specifically.

Alternatively, couldn't you just say that in situations where a CA requires CAA, it MUST NOT issue if there are no CAA records provisioned for the target domain?  It seems like that would be simpler (as a true default-deny), and would address your use case without the need for tree-walking.

Also, the need to carve out exceptions goes away if you only look at the leaf.

> TLDs like .uk are structured.

OK.  I did not realize this.  I certainly agree it's fuzzy!  

Is there any guidance you could point to on how a CA should determine what domains are public delegation points?  What happens if it guesses wrong?  If a CA doesn't know anything about public delegation points, is it safe to just go all the way to the root?  

> CABForum folk for an opinion. We have no shortage of lawyers.

I'm not trying to bring lawyers to bear on this document, I'm trying to keep them out :)

The text in question simply isn't technically relevant or useful, and could be wrong in some places.  

(What does this have to do with audit?)

> CAA records are intelligence, but they are not directly actionable

Could you provide an example of a Certificate Evaluator in the real world?  

> authorized to issue for Comodo or Symantec on the basis of a phone

That seems like it's up to the CA!  I don't see much reason why an XMPP message should have less authority than an email -- they're both just bits.

This is a policy/legal-level requirement, not a technical one.

> tags be lower case is a low cost way to avoid ambiguity and confusion

I don't really agree that lower case has any benefit.  Requiring it to be lower case just means that someone has to check this and reject.  If you want case not to cause mismatches, make it case insensitive.  If you want to make matching simple make it case sensitive and allow both cases.

Still think that there needs to be ABNF for this.

> We have a very good reason for requiring climbing.

As noted above, it would be helpful to explain that the reason is (2), i.e., that the policy is different if there is a CAA vs. if there isn't, even if the CAA is empty.  So showing that you understand CAA activates the default-deny policy.

Also as above, it would be simpler if this mechanism could be true default-deny.

> principally a document for the auditors to work against.

What statement are you referring to?  In RFC 3647, I see only a "Certificate Policy" and a "Certification Practice Statement", not "Certificate Policy Statement".

Maybe you mean "Certificate Policy"?  It seems like a mention of CAA would fit under the "Certificate Application Processing" heading:
<http://tools.ietf.org/html/rfc3647#section-4.4.2>

> draft to one particular body as there may be others.

Hence the "can be", as in "Someone can do this if they want to".  Like CABF.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Jul 2012 10:22:11 -0400

> Was the possibility of looking only at the leaf node discussed?  It seems like if you're requesting a cert for a domain, you should be authorized to provision a record for that domain, so walking u…

Today the practice for validation checks is to ONLY check for the
public delegation point. Subdomains are not a concern for CAs, they
are assumed to be purely a matter of internal administrative policy.

The number of domains where this is not the case is vanishingly small.
Yes, at MIT there are subdomains for the departments but outside CSAIL
they are all run by the MIT network staff anyway.

Checking the leaf node only would make no sense at all to me, consider
the cases for leaf.example.com and example.com

1) No CAA record at either - anyone can issue

2) CAA record at example.com for Alice.ca,
     only Alice can issue for *.example.com

3) CAA record at leaf.example.com for Bob.ca,
     only Bob can issue for leaf.example,com, anyone can issue for the rest

4) CAA record at leaf.example.com for Bob.ca, CAA record at
example.com for Alice.ca,
     only Bob can issue for leaf.example,com, anyone can issue for the rest

You seem to be arguing that in case 2, anyone could issue for
leaf.example.com. That seems like nonsense to me.

> Alternatively, couldn't you just say that in situations where a CA requires CAA, it MUST NOT issue if there are no CAA records provisioned for the target domain?  It seems like that would be simple…

Are you seriously suggesting that CAs are going to deploy a spec that
required every one of their customers to deploy a new record before
they could issue a cert?

> Also, the need to carve out exceptions goes away if you only look at the leaf.

So does the effectiveness of the control.

> Is there any guidance you could point to on how a CA should determine what domains are public delegation points?  What happens if it guesses wrong?  If a CA doesn't know anything about public deleg…

That is all stuff that represents 'policy' which would have to be
harmonized in CABForum if it is going to be harmonized anywhere.

One of the new corner cases is that we now have a real possibility of
TLDs that are going to not be public delegation points like .google
and .apple.

> (What does this have to do with audit?)

Once we get CAA signed off here, the next stage is to have it adopted
as a Basic Requirement for validation by CABForum. At which point
compliance with CAA will become an audit requirement within a couple
of years.

This is an accountability control and so the enforcement is by
consequences and not purely technical.

> Could you provide an example of a Certificate Evaluator in the real world?

Comodo CertSentry, Kasperky also have a product. I would expect McAfee
and Symantec also have ideas for product.

Before that we had the EFF certificate observatory, Convergence and
Perspectives. Though I suspect those will be seen as forerunners of
the commercial services as open source services don't scale quite the
same way as open source software as the marginal cost of service is
negligible rather than zero and those negligible amounts add up.

I have a draft out on an open protocol, reference code to follow:

http://www.ietf.org/id/draft-hallambaker-omnibroker-00.txt

> That seems like it's up to the CA!  I don't see much reason why an XMPP message should have less authority than an email -- they're both just bits.

The point is that you have to save it.

If you have a saved jabber log, well it might count. But since jabber
is a conversation, well I don't think I would rely on it for authority
to issue on behalf of Symantec.

> This is a policy/legal-level requirement, not a technical one.

As is pretty much the whole subject matter of PKI.

> Also as above, it would be simpler if this mechanism could be true default-deny.

And a non-starter for deployment.

> <http://tools.ietf.org/html/rfc3647#section-4.4.2>

Ah, the word statement should have been killed.

> Hence the "can be", as in "Someone can do this if they want to".  Like CABF.

I think that counts as normative language.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 11 Jul 2012 22:52:26 -0400

> leaf.example.com. That seems like nonsense to me.

No, I'm saying that the policy should be default-deny with authorizations applying to specific names (not sub-domains).  

1) No CAA record: 
   Nobody is authorized to issue

2) CAA at example.com for Alice: 
   Only Alice can issue for example.com (exactly)
   Nobody is authorized to issue for any other name

3) CAA at leaf.example.com for Bob: 
   Only Bob can issue for leaf.example.com (exactly)
   Nobody is authorized to issue for any other name

4) CAA at leaf.example.com/Bob, example.com/Alice:
   Only Bob can issue for leaf.example.com
   Only Alice can issue for example.com
   Nobody is authorized to issue for any other name

It seems like what you want is an explicit assertion that flows down (as opposed to a global default deny).  That's a different semantic than the positive authorization that the "issue" tag creates.  Why not just create another  

> required every one of their customers to deploy a new record before

No, I'm saying that "in situations where the CA requires CAA", the customer would be required to provision a record.  Which situations require CAA would be up to a CA's Certificate Policy.

All this document defines is a standard version of Google's "set a TXT record with a validation token" verification protocol for Google Apps.  That protocol (1) only looks at the leaf, (2) doesn't require a DNS record in all cases, and (3) works.
<http://support.google.com/a/bin/topic.py?hl=en&topic=9196>

> TLDs that are going to not be public delegation points like .google

This seems like all the more reason to avoid tree walking.

> consequences and not purely technical.

If we're seriously going to do legal stuff here, then we need to actually have some lawyers review the document.  Has that been done?  Otherwise, let's take the legal language out.

We do not have to broach legal topics in this document in order for it to be a useful accountability control.  If we define a clear technical mechanism, then the CABF or some other group can define how that technical mechanism should be used and wrap legal requirements around it.  

> http://www.ietf.org/id/draft-hallambaker-omnibroker-00.txt

OK.  Leave it in if you want.  I still don't really find it all that helpful; these entities exist already (based on certs and CRLs) without a need for standards guidance.

> As is pretty much the whole subject matter of PKI.

Like I said above, if this document is going to specify legal requirements, then bring in the lawyers.  (Cf. RFC 3647)  Otherwise, just leave it out, and leave the lawyering to the attorneys at the CAs / CABF.  

> And a non-starter for deployment.

See the Google example above.  They require every single one of their Google Apps customers to deploy a domain name or a special web page.  This has not killed their deployment.

This document also doesn't say that every CA in the world has to require CAA for every transaction.  It says "If you're using CAA for authorization, here's where you look and what the octets mean."  CA policy says when you use CAA for authorization.

> I think that counts as normative language.

I don't see "CAN BE" in RFC 2119.  How can the expression of an existential possibility be normative?  If I say, "Cookies can be delicious, but they can also be too chewy", how do you write a compliance test for that?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jul 2012 12:12:30 -0400

>    Nobody is authorized to issue

Non starter, not going to happen for reasons that are obvious. No CA
is ever going to process CAA records under that restriction.

I suggest that before you continue with this line you need to find a
CA with an embedded trust anchor (aka public root) that would be
willing to deploy if your proposal was approved. I think you will find
the number is zero.

I am all for default deny security, it is the name of my private
consulting company for a start.

> <http://support.google.com/a/bin/topic.py?hl=en&topic=9196>

That is a different situation. It is easy to set security criteria
when deploying a completely new scheme.  Adding requirements to a
deployed scheme is much harder.

> We do not have to broach legal topics in this document in order for it to be a useful accountability control.  If we define a clear technical mechanism, then the CABF or some other group can define…

I will remove the mention of sanctions and reword to something like
"intentionally make a false representation to obtain an audit" that
work for you?

> Like I said above, if this document is going to specify legal requirements, then bring in the lawyers.  (Cf. RFC 3647)  Otherwise, just leave it out, and leave the lawyering to the attorneys at the…

I think what you are really asking here is for the avoidance of
lawyers to rewrite the statement in a form that the lawyers will no
longer understand and will lead to ambiguity rather than use a term of
art.

When lawyers do the same we go nuts and with good cause.

> This document also doesn't say that every CA in the world has to require CAA for every transaction.  It says "If you're using CAA for authorization, here's where you look and what the octets mean."…

No but the statement that the CABForum has asked me to draft does
precisely that. But they are not going to accept this specification if
it is going to make issue of certs dependent on deployment of CAA.

I think that you really need to consider whether you should be doing
this GenArt review. This seems to me to be a wrecking amendment.

> I don't see "CAN BE" in RFC 2119.  How can the expression of an existential possibility be normative?  If I say, "Cookies can be delicious, but they can also be too chewy", how do you write a compl…

OK it is a statement of fact so it does not need to be normative. It
does not define a choice that the CA or any party can make.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jul 2012 09:46:16 -0700

> is ever going to process CAA records under that restriction.

+1 to Phill here. I would have never supported this document if that was a design requirement. (The rest of Richard's more recent suggestion seems predicated on this, so I don't think I need to rebut it as Phill did.)

--Paul Hoffman

---

From: Richard L. Barnes <[email-masked]>
Date: Thu, 12 Jul 2012 14:56:37 -0400

> consulting company for a start.

We must be talking past each other here.  I don't think what I'm proposing here is radical, just that CAA actually be a default-deny/positive-authorization system in terms of its internal semantics.  It's still a CA's choice when to apply these semantics, and when to apply other authorization mechanisms.  

Indeed, several other IETF technologies follow the design pattern I'm proposing.  RFC 5280 doesn't tell a Relying Party when to require a certificate, only how to interpret a certificate if once he gets one.  TLS doesn't tell a server when it needs to require a client cert, just what to do if one does.  The CAA specification shouldn't specify *when* a CA needs to require a CAA record be present, only how to find and interpret a CAA record if one is required.

So in the above, "Nobody is authorized to issue" really means "Nobody is authorized to issue *by* *CAA*".  That is, it doesn't mean "A CA MUST NOT issue", it says "A CA MUST NOT issue if it requires a CAA authorization."  If the CA's CP allows it to use some other form of authorization, then it can use that.

> deployed scheme is much harder.

Not in this case: The presence or absence of the new mechanism is clear to the CA.  If the new authorization is absent (no CAA), then the CA can fall back to whatever it did before -- or it can choose not to issue.  

> "intentionally make a false representation to obtain an audit" that

Removing the mention of sanctions sound good, but I'm not sure revision you're proposing otherwise.  Making statements about "intention" and "false representation" makes me generally uneasy, again because terms that lawyers know much better than us.

If I were to suggest something, I think it would still be my original suggestion.  
OLD: "It is thus unlikely that the attack would succeed and the attempt might lay the perpetrator open to civil or criminal sanctions."
NEW: "It is thus unlikely that the attack would succeed."   

We've already called this usage of the "critical" flag an "attack", "abuse", and "deception".  So I think it's clear enough that it is an undesirable action, regardless of any specific legal consequences.

> When lawyers do the same we go nuts and with good cause.

Let me be a little more concrete.  I would make the following change to the text:
OLD: "party acting under the express written authority of the holder"
NEW: "party acting under the authority of the holder"

Lawyers can then decide how that authority is delegated, whether IM, email, blood oath, etc.  They're good at that sort of thing.

> this GenArt review. This seems to me to be a wrecking amendment.

There's nothing special about a Gen-ART review.
"
Gen-ART review comments should be treated as any other IETF last Call comment. The comments become blocking only if the IESG review process makes them so. That is, one of the Area Directors, agrees with the comments and incorporates them in their IESG ballot as"DISCUSS" comments. Gen-ART does not have a formal role in the standards approval process; they are simply providing input to the General AD.
"
<http://www.ietf.org/iesg/directorate/gen-art.html>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jul 2012 18:15:01 -0400

> We must be talking past each other here.  I don't think what I'm proposing here is radical, just that CAA actually be a default-deny/positive-authorization system in terms of its internal semantics…

Quite. You seem to think that the presence of this record indicates an
authority to issue without any other checks. That is not the case at
all.

All it states is that if there is a CAA record set and you are not a
member of the authorized set then you MUST NOT issue.

If you are the CA specified you still have to meet all the
requirements of your practices plus any additional requirements that
you may have agreed out of band.

> Indeed, several other IETF technologies follow the design pattern I'm proposing.  RFC 5280 doesn't tell a Relying Party when to require a certificate, only how to interpret a certificate if once he…

Which is exactly how it works. If there is no CAA record that means
that the domain holder is not deploying CAA controls. If there is at
least one CAA record then the domain is under CAA control. If the
holder wishes that nobody be allowed to issue then they put in an
empty authorization.

> Not in this case: The presence or absence of the new mechanism is clear to the CA.  If the new authorization is absent (no CAA), then the CA can fall back to whatever it did before -- or it can cho…

That is what the text says to do.

We have a situation where we are moving from a default permit
situation to one where we have access controls. We cannot transition
to default deny immediately.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 21:20:49 -0400

> you may have agreed out of band.

OK, I think we are starting to converge.  I talked with Paul this afternoon, and he made me realize how poor my wording is here.  I used the phrase "Nobody is authorized" without noting "neither is anyone prohibited".  So let me go back to the original cases and try to say what I meant more clearly, using some RFC 2119 language.

1) No CAA record: 
   Any CA MAY issue

2) CAA at example.com for Alice: 
   Alice MAY issue for example.com (exactly)
   CAs other than Alice MUST NOT issue for example.com (exactly)
   Any CA MAY issue for any other name (no impact on other names)

3) CAA at leaf.example.com for Bob: 
   Bob MAY issue for leaf.example.com (exactly)
   CAs other than Bob MUST NOT issue for leaf.example.com (exactly)
   Any CA MAY issue for any other name (no impact on other names)

4) CAA at leaf.example.com/Bob, example.com/Alice:
   Bob MAY issue for leaf.example.com
   CAs other than Bob MUST NOT issue for leaf.example.com
   Alice MAY issue for example.com
   CAs other than Alice MUST NOT issue for example.com
   Any CA MAY issue for any other name (no impact on other names)

And in reality, the MAYs here actually mean "MAY, subject to other provisions of the CP".

Comparing these to your original responses, ISTM that the only difference is with respect to case (2):
RLB: Alice MAY issue for example.com
     CAs other than Alice MUST NOT issue for example.com
     CAs other than Alice MAY issue for *.example.com
PHB: Alice MAY issue for *.example.com (others MUST NOT)
     CAs other than Alice MUST NOT issue for *.example.com

This brings us back to what we were talking about originally, namely tree climbing.  In your (2), the RP/Evaluator has to climb up from the leaf to find whether there's some parent domain that has a CAA.  What I'm suggesting is that you just omit the tree climbing and only look at the leaf.  

That removes the complexity of the tree climbing and the ambiguity about delegation points. The only cost is if someone wants to register enough subdomains that provisioning CAAs is painful, but not enough for a wildcard CAA.

> to default deny immediately.

It's becoming increasingly apparent that what we're both talking about isn't really "default deny", it's "default no information" -- by default, issuance is neither authorized nor denied.  The becomes "default deny" only if a CP construes "lack of CAA authorization" to imply "deny", as opposed to "use some other verification mechanism".

Thanks for bearing with me on this,
--Richard

---

From: Scott Schmit <[email-masked]>
Date: Thu, 12 Jul 2012 21:30:42 -0400

On Thu, Jul 12, 2012 at 09:20:49PM -0400, Richard L. Barnes wrote:
> That removes the complexity of the tree climbing and the ambiguity
> about delegation points. The only cost is if someone wants to register
> enough subdomains that provisioning CAAs is painful, but not enough
> for a wildcard CAA.

Actually, that brings up an important question: how does a CA using CAA
know that it's allowed to issue a wildcard certificate?

I was going to say using Richard's scheme, but I suppose it could apply
to PHB's too.

-- 
Scott Schmit

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 12 Jul 2012 21:45:42 -0400

> I was going to say using Richard's scheme, but I suppose it could apply

Well, the simple answer is "don't issue wildcard certificates" :)

A few possibilities:

OPTION 0: CA randomly samples N names matching the wildcard.  But that's just silly.

OPTION 1: CA checks for CAA at the label above the wildcard. 

In the RLB scheme, that would create the somewhat weird situation that a CAA at example.com would authorize an issuer to issue for *.example.com, but not for leaf.example.com specifically.  But in either case, the CA processing is deterministic; you just make one query.  In the PHB scheme, there's not that wrinkle in the semantics, but you have to do tree climbing even in the simple case.   

OPTION 2: CA looks for CAA under a special label _wildcard.example.com.

This avoids the conflict with example.com, in the sense that you can authorize a wildcard without authorizing the domain itself.  It also resolves the weird situation in the RLB scheme.  

My vote would be for OPTION 2.  Labels are cheap.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jul 2012 22:01:39 -0400

The wildcard cert is of the form *.suffix, so the test would have to
start at suffix.

But good catch, it should be specified in the draft. I will fix that.

On Thu, Jul 12, 2012 at 9:30 PM, Scott Schmit <[email-masked]> wrote:
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jul 2012 22:05:07 -0400

The problems of using prefixed DNS labels are the reason that we
applied for the RR in the first place.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 13:07:06 -0400

Could you elaborate?  OPTION 2 wouldn't use prefixes in general, just for the special case of wildcards.  It's effectively a label for the "*" in the wildcard.  We could use the prefix _star if you want :)

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 14:14:28 -0400

I don't see any value in distinguishing between the cases.

As far as I am aware, all the CPs for public CAs mean that they
validate a request for a cert for www.paypal.com by verifying that the
applicant has the right to use paypal.com.

The substructure of the DNS is not a concern of public CAs. Never has
been. If an enterprise is large enough for the substructure to matter
then they are going to be large enough to demand special casing.

The only cases where this has ever been an issue are for weird cases
like Oxford colleges which have DNS names like wolfson.ox.ac.uk which
is a 4th level domain despite the fact that Wolfson has an independent
existence outside the University. It has a separate royal charter for
a start.

But from a CA point of view this is all moot. What I am interested in
if I get an application is that (1) the subject is the party they
purport to be and (2) they have the right to use the network names
they claim. So even though my college has an independent existence
outside of Oxford University, they can only get a certificate if the
holder of ox.ac.uk agrees that they have the right to use that name.

The specification as written allows that Wolfson can specify their own
certificate issue criteria for wolfson.ox.ac.uk if the OUCS allows
them to run their own DNS or insert the relevant records. And
otherwise OUCS can restrict their ability to obtain certs if they
happen to choose.

The specification as written has exactly the degree of flexibility
intended to meet the real world use cases. Your proposed alternative
does not. Nor is it possible to reliably obtain the desired semantics
from your method using wildcards.

And even if we could do it the way you propose, I cannot see any
benefit to doing so. The cost of making multiple checks is
insignificant in the context of a certificate issue process, even in
the case of a corner case very long DNS name. Now I might well want to
think twice about issuing certs for names like a.b.c.d.e.f. ...
example.com without some human review as well, anything weird deserves
a human pair of eyes.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 13 Jul 2012 14:30:33 -0400

If we were to build a system according to the policy you're specifying, then there wouldn't be any tree-climbing either -- you would just check for CAA at the public delegation point.  There would be no point to starting at the leaf.  I would still be a little queasy with that, given how ill-defined the notion of a public delegation point is, but at least it would be less complex than the current document.  And the semantic would be clearer: A CAA record would authorize an issuer to issue for any sub-domain.

I find all this discussion about the loose practices of CAs very interesting.  But I don't think we should design an authorization system around ill-defined concepts when a semantically cleaner version is available and just as easy to use.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Jul 2012 13:48:00 -0400

CAA-11 is pending. All the changes made are strictly
editorial/wordsmithing. There has been no change to the semantics.

I have not changed the tree climbing algorithm but I have responded to
most/all of the other points raised.

Here is the change list

Mention of Dane in the introduction:

        Like the TLSA record defined in DNS-Based Authentication of
Named Entities (DANE)
        [DANE], CAA records are used as a part of a mechanism for checking PKIX
        certificate data. The distinction between the two specifications is that
        CAA records specify a authorization control to be performed by
a certificate
        issuer before issue of a certificate and TLSA records specify
a verification
        control to be performed by a Relying Party after the
certificate is issued.

If DANE ends up in a blackhole for some reason then we can take this
statement out and DANE can mention CAA instead. But that does not look
likely to happen as DANE is in the editor queue already.

Since these are both going to be PROPOSED (or is it draft?) standards
this time round, I think that is the limit for what we need to do at
this stage. Lets see how both of these mechanisms work on their own
before we work out how they might interoperate in detail.

Section 5.4 criminal sanctions - I just removed the last sentence
entirely as superfluous and changed the wording slightly. I think it
is obvious enough that lying to your customers is a bad business model
for an Internet firm in the trust business.

        In practice, such an attack would be of minimal effect since
        any competent competitor that found itself unable to issue certificates
        due to lack of support for a property marked critical SHOULD
        investigate the cause and report the reason to the customer
        who will thus discover that they had been deceived.

Express written authority -> Explicit Authority

The issue property entry authorizes the holder of the
              domain name &lt;Issuer Domain Name&gt; or a party acting
under the
              explicit authority of the holder of that domain name to issue
              certificates for the domain in which the property is published.

Mention of DANE in the security considerations, I bumped the part
about non-observance by CAs out into an explicit subsection and
reworded the intro part thus:

.      <t>
        CAA Records assert a security policy that the holder of a domain name
        wishes to be observed by certificate issuers. The effectiveness of CAA
        records as an access control mechanism is thus dependent on
observance of CAA
        constraints by issuers.
      </t>
      <t>
        The objective of the CAA record properties described in this document is
        to reduce the risk of certificate mis-issue rather than avoid
reliance on
        a certificate that has ben mis-issued.
        DANE <xref target="DANE"/> describes a mechanism for avoiding reliance
        on mis-issued certificates.
      </t>

Certificate Policy Statement -> Certificate Policy

This was just a typo.

Mention of RID in section 2.1 - done

'observance by CAs' - removed almost everything and replaced with:

      <section title="Non-Compliance by Certification Authority">
        <t>
          CAA records offer CAs a cost-effective means of mitigating the risk
          of certificate mis-issue: The cost of implementing CAA checks is
          very small and the potential costs of a mis-issue event include the
          removal of an embedded trust anchor.
        </t>

I don't think any more than that is really needed.

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Jul 2012 01:49:17 +0200 (CEST)

Phillip Hallam-Baker wrote:
>    Named Entities (DANE) [DANE], CAA records are used as a part
>    of a mechanism for checking PKIX certificate data. The
>    distinction between the two specifications is that CAA records
>    specify a authorization control to be performed by a certificate
>    a verification control to be performed by a Relying Party after the
>    certificate is issued.

Personally, I believe that CAA should *not* be "liked" to DANE, because
it is very unlike DANE TLSA records.

           CAA                              DANE TLSA
   should be used by CAs               MUST NOT be used CAs.
   MUST NOT be used by RPs             SHOULD be used by RPs

   cert pre-issuance check only        is irrelevant for new cert issuance
   does not apply to existing certs    applies to existing certs only

CAA is information placed in the DNS addressed to certification
authorities, and can be used to limit acceptable certificate issuers
for issuing new/further certificates.  This information does not apply
to existing certificates.  DANE TLSA records is information placed in the
DNS and addressed to relying parties, meant to be used for verifying
certificates that presented by communication peers for authentication.

-Martin