Subject: [keyassure] Revised version of CAA

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Dec 2010 12:09:38 -0500

All, a new version of CAA is available. This has been developed with
the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
proposal and is not intended to pre-empt or foreclose discussion here.

http://tools.ietf.org/html/draft-hallambaker-donotissue-01

This version has significant changes from the last one. Some of which
may be relevant to KIDNS depending on what use cases are to be
considered. It should be noted however that the original use case for
CAA is outside the scope proposed for KIDNS, although the scheme
proposed is capable of use for purposes that are in scope.

In particular, the Object Digest Identifier is a general purpose
mechanism for providing a cryptographically authenticated reference to
an object instance by means of an ASN.1 structure as follows:

   DNSCAA DEFINITIONS ::=

   BEGIN

    ObjectDigestIdentifier ::= SEQUENCE {
      type             OBJECT IDENTIFIER,
      digestAlgorithm  OBJECT IDENTIFIER,
      digest           OCTET STRING
    }

   END

Thus the ODI of the certificate used in the example in Base64 format is:

MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
   zKv6mI2D0yilif+7WhzmhMGLe/oBA==

This construction provides protection against a digest substitution
attack and a semantic substitution attack without a major increase in
the size of the digest value. While people may argue over the
relevance of such attacks to specific applications, it is the type of
issue that I much prefer to simply anticipate and dispose of in
advance.

The use of ASN.1 for this purpose is ideal since it is a very compact
format and widely used and supported in crypto libraries. While a full
ASN.1 implementation is considerably tedious and complex, the ODI only
uses a small subset that can be easily implemented without much
additional code. In effect the type and digestAlgorithm fields only
add a fixed constant string to the front of the items in question.

It would be rather nice if ODI digests could be emitted by
cryptographic applications as a general purpose 'fingerprint' that is
usable in multiple contexts. So the emitted digest can just be cut and
pasted from one place to another.

For example, it would be nice if we could have something like the
following in an HTML file:

<img href="http://blah.com/blah.jpg"
odi="digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7WhzmhMGLe/oBA=="/>

We have just created a transcluded reference to the object blah.jpg
which is authenticated by a secure digest value. The client could
reject the content if it does not match.

This approach is slightly less efficient space wise than the use of
DNSSEC code points for this purpose but has the advantage that there
is no need for additional registry maintenance effort when adding new
algorithms. There are very good reasons for wanting to keep the set of
digest algorithms used in DNSSEC small. There are less good reasons
for applying that to certificates. So I would not be surprised if the
DNSEXT group would end up preferring this approach on consideration.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 6 Dec 2010 16:46:36 -0500

Just to be clear about scope/placement, I think this draft is pretty clearly within the domain of this working group.  I realize that the intended audience for these records is CAs, but they could just as easily be interpreted by clients and integrated into the TLS certificate acceptance process.  

That said, on a quick read, this draft has some good ideas.  Certainly, the notion of a domain indicating what CA(s) MUST be in the chain seems useful.  Given that there are other useful constraints that are being discussed, however, I would prefer that this document be integrated in a more general framework for making statements about what certificates will be presented for a domain.  (I'm also a little leery of the use of words like "anticompetitive" in a specification; "abuse of the critical flag" might be a little more appropriate.)

In any case, though, thanks to the authors for putting the draft forward.  Looking forward to doing a more thorough review and to more discussion,

--Richard

On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Dec 2010 19:02:08 -0500

OK, consider the word 'anticompetitive' struck.

Given the number of moving parts here, I would really prefer to try to
avoid making moving ahead on the CA-Auth part dependent on deciding a
wider scheme.

The client side enforcement is a somewhat larger problem and the
problem there is that once code is deployed it is much harder to dig
ourselves out if we decide we want to do it differently.

The only parties that need to be involved in the CA-auth part is the
domains and the CAs. So if we decide that we want to take a different
approach on the client side enforcement front, we can easily require
the CAs to check an extra record as well.

That said, I am pretty confident that tag-value pairs with a
criticality flag should be enough to cover what we need. And we can
use additional RRs if we need to.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 6 Dec 2010 23:09:51 -0500

The thing that's troubling me a little here is that it's not clear to me that it's possible to separate the CA-Auth part from the UA part, i.e., the part where the UA decides what certs to accept.

A CAA record says that a CA is authorized to issue certs for a domain.  If you interpret this literally, it's a noop for UAs, since the UA knows what CAs it's willing to trust, regardless of this record.  However, it seems like it will be tempting for people to infer the contrapositive, that the absence of a record implies that a CA is not authorized -- especially if a domain has a CAA record for some other CA.

If I read "relying party" as "UA", then the inclusion of the "Relying Party Authorization Set" concept and the "Relying Party" flag seem to encourage this line of thinking even more.  If you really don't intend for this to be used by UAs, then these should be scrapped as well.

Going beyond my conceptual worries, here are some technical comments and nits:

Section 2.1: Specifying constraints by CP OID doesn't seem very effective.  A CA doesn't have to use only its own policy OIDs -- a bad CA could insert an authorized CP OID into a certificate even if it's in someone else's arc.  Also, it's not clear whether the CP OID being specified here is required to be in the CA cert or the EE cert (although the wording makes me suspect the former).

Section 2.1: The "path" property seems underspecified.  It seems like you probably want to constrain the "type" field so that any old OID can't be shoved in there.  It doesn't seem like it would be meaningful for me to specify a path attribute of type 2.5.4.51, id-at-houseIdentifier.

Section 2.1: The use of the acronym "ODI" is a little confusing next to "OID".  A forward reference to Appendix A would be helpful.

Section 2: both "Certificate Policy Statement" and "Certificate Practices Statement" should be "Certification Practice Statement"

Section 3.1.2: I'm not sure what the phrase "To be honest" is doing there :)

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 6 Dec 2010 21:03:09 -0800

>From my perspective, this (and all other similar DNS records) are
*completely useless* unless they do influence which certs a UA
ultimately decides to accept.  And exclusive assertions ("these
CAs/these specific certs, and no others") are enormously more useful
than nonexclusive ones ("these CAs, or maybe some other CA if you feel
like it") -- to the point where I'm not sure I would bother adding
support to a UA for anything *but* exclusive assertions.

I'm a UA guy, so maybe I just don't know about the thing these would
be useful for if they're not useful to me.

zw

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 7 Dec 2010 00:36:45 -0500

To be fair, I think there is a separate problem that this draft is trying to solve.  As I understand it, it seems like it kind of gives CAs a way to have their customers provide them a signed statement that they authorize the CA to issue a certificate.  So it's more about assuring the issuance process than the UA acceptance process.

(Caveat: Not the author, may be misunderstanding.)

--Richard

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Dec 2010 08:04:50 +0200

On Mon, Dec 06, 2010 at 09:03:09PM -0800, Zack Weinberg wrote:
> ultimately decides to accept.

There are three cases:
1) Mistaken issuance by CAA-following CA.
2) Mistaken issuance by non-CAA-following CA.
3) Maliscous issuance.

Non-client-enforceable statement is completely useless against 3),
and would only help against 1). Unfortunately, CAs (and how many there
effectively are, nobody knows!) that mistakenly issue tend to be
those otherwise careless ones that probably wouldn't follow CAA.

Mistaken issuance should be rare. How often maliscous issuance happens
is unknown (mostly because X.509 provodes no provision to audit
certificates used at large scale, making maliscous issuance hard
to detect).

> And exclusive assertions ("these CAs/these specific certs, and no
> others") are enormously more useful than nonexclusive ones
> ("these CAs, or maybe some other CA if you feel like it") 
> -- to the point where I'm not sure I would bother adding

I haven't run across case where one would need nonexclusive
assertion, assuming asserting higher-up certificates is possible.

With asserting higher-up certificates, one has to be careful with
bad sub-CA attacks.

-Ilari

---

From: Paul Wouters <[email-masked]>
Date: Tue, 7 Dec 2010 01:16:43 -0500 (EST)

> To be fair, I think there is a separate problem that this draft is trying to solve.  As I understand it, it seems like it kind of gives CAs a way to have their customers provide them a signed state…

Correct. It uses DNSSEC authentication and the path of trust from
the DNSSEC Root key to the domain to reduce the amount of authorized
Certificate Agencies that can sign for your record from "a whole lot"
(I've heard numbers of 1500 but that mighe be an exaggeration) to 1 (or
perhaps a few, though it is unclear what one would do if the few disagree)

This CA in turn then, via another trust model, depending on the CA
and the requested cert type, some backed by legal process, vouches your
cert used in your domain. These lists of CA's are preloaded either on a
network/host or on an application level, without much hierarchy. You either
trust what they sign, or you don't. Often the only limit on these is that
they cannot sign another CA. Hence the desire to restrict them via DNSSEC
after such incidents as the false Microsoft cert, the *\0 cert valid for
everything, or the rapidssl crafted certificate signature swap.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 6 Dec 2010 22:20:16 -0800

On Mon, Dec 6, 2010 at 10:16 PM, Paul Wouters <[email-masked]> wrote:
>> To be fair, I think there is a separate problem that this draft is trying
>> to solve.  As I understand it, it seems like it kind of gives CAs a way to
>> have their customers provide them a signed statement that they authorize the
>> CA to issue a certificate.  So it's more about assuring the issuance process
>> than the UA acceptance process.
>

But if the UA doesn't check, I see no actual gain in security to the
end user.  Ilauri's analysis matches mine.

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 07:57:21 -0500

There are two modes of security control.

Network security has tended to be over-invested in access controls and
neglect accountability controls. An effective security system requires
both.

Access controls explicitly specify what is permitted and what is
denied. Since it is rarely possible to specify these exactly, the
range of actions allowed in an access control regime will almost
always be more than is desirable.

Accountability controls address the gaps. I can't stop people sending
spam but we can block the IP addresses used by spammers and we can
send them to jail if caught.

The issuer side of CAA is an accountability control. It does not make
mis-issue impossible but it does increase the risk of consequences in
the case of default.

As such, the fact that one CA could issue under a policy OID owned by
another is not relevant to the design. Any CA can ignore CAA records
if they are prepared to accept the consequences.

CAA-01 presents what we believe to be a complete specification as far
as the accountability controls for the issuer side are concerned. From
a design point of view this is somewhat easier since accountability
controls do not require the same degree of precision as access
controls.

CAA-01 also presents a mechanism that may prove useful as the basis
for an access control. Or it may not. At this point we think we have
probably got as far as we can with that approach before we need to
attempt some field trials.

I would think that we would almost certainly want to have more
expressive power in an access control design that is suitable for
client enforcement. For example, protocol specific properties. But
that adds some complexity to the design. For example CAA records are
intended to be used with wildcards which means that they cannot be
used as protocol prefixed records as well.

There are many reasons for wanting to do the issuer side first. One of
the most important is that we can get deployment very quickly. All the
CAs need is the RR code assignment and we can start putting that
protection in place.

Another important reason to do the issuer side first is that it is
going to help the larger sites bring their systems under control. A
lot of larger enterprises found DKIM deployment hard because they did
not know where all their mail servers are. The reason CAA is needed is
because sites have the same problem with SSL certs.

This is why the design is specified so as to allow sites to turn on
issue restrictions independent of client enforcement. It is also why
we found it essential to consider the client enforcement at the same
time. If the spec did not anticipate client enforcement and allow for
orderly introduction, there was a risk that some people would attempt
client enforcement on the basis of incomplete data.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Dec 2010 14:52:38 +0000

> If I read "relying party" as "UA", then the inclusion of the "Relying Party Authorization Set" concept and the "Relying Party" flag seem to encourage this line of thinking even more.  If you really…

I do intend for these to be used by UAs.

> Section 2.1: Specifying constraints by CP OID doesn't seem very effective.  A CA doesn't have to use only its own policy OIDs -- a bad CA could insert an authorized CP OID into a certificate even i…

I also wondered about that, but the CA experts assured me it didn't
work like that. I had forgotten that I asked them to add an
explanation to the I-D.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 07:11:22 -0800

At 7:57 AM -0500 12/7/10, Phillip Hallam-Baker wrote:
>. . .
>. . .

At 2:52 PM +0000 12/7/10, Ben Laurie wrote:
> >... this line of thinking even more.  If you really don't intend for this to be used by UAs, then these should be scrapped as well.
>

If two of the three co-authors on this draft cannot agree on the semantics, then it is maybe premature for them to expect the Internet community to do so.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 10:11:19 -0500

> Section 2.1: Specifying constraints by CP OID doesn't seem very effective.  A CA doesn't have to use only its own policy OIDs -- a bad CA could insert an authorized CP OID into a certificate even i…

For user agent enforcement, the policy OID approach is not ideal. But
one important case is 'must be EV certificate'. Where there are in
fact mechanisms to enforce issue restrictions.

This is something we can get into further as we look at the relying
party problem in more detail.

> Section 2.1: The "path" property seems underspecified.  It seems like you probably want to constrain the "type" field so that any old OID can't be shoved in there.  It doesn't seem like it would be…

If a domain publishes an OID that a CA does not understand, they
cannot rely on it as an authorization entry.

I did think about adding restrictions there, but they don't matter on
the issue side and on the relying party side they are still going to
come down to 'ignore'.

> Section 2.1: The use of the acronym "ODI" is a little confusing next to "OID".  A forward reference to Appendix A would be helpful.

ODR? Object Digest Reference?

Pronounced 'Oh Dear'?

Yes, the name of the ODI is the biggest problem we have with it right now.

> Section 2: both "Certificate Policy Statement" and "Certificate Practices Statement" should be "Certification Practice Statement"

No, there is an important difference between the two and it is
relevant to this spec.

A CP is a statement of requirements. A CPS is a statement of
implementation that the audit is performed against.

A CP should have constant intent over time. The CPS will tend to vary
according to circumstances. So for example, the VeriSign class 3 CP
has been essentially constant over the years but the CPS has had
numerous revisions to change crypto requirements, describe key
management process changes and so on.

The OID relates to the CP and not to the CPS. But the CPS may have a
specific requirement to check the CAA records in specific ways.

These may have got switched over the course of editing, but that is
the intent at any rate.

> Section 3.1.2: I'm not sure what the phrase "To be honest" is doing there :)

It was a chat window by the looks.

I have updated the spec with the other changes so far.
--
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 10:27:15 -0500

That would be why the draft is marked EXPERIMENTAL.

We are all agreed on what we want to do here. As I mentioned in my
other post, design of an access control is much trickier than design
of an accountability control. And with an access control you may only
get one shot.

So while I am very confident that we have the issuer side completely
covered at this point, I am very cautious and I want to see how this
works in practice on the user agent side.

I suspect that it is likely that we will require more properties to
fully support relying party needs. I have the designs in hand, I can
easily write them up.

The reason that I do not want to do that right now is that I want to
see how much coverage of the requirements I can get from implementing
just the two properties given in CAA. And I can only do that with real
world experiments and feedback from the organizations who have told me
that they are interested in field trials.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Dec 2010 15:32:32 +0000

> If two of the three co-authors on this draft cannot agree on the semantics, then it is maybe premature for them to expect the Internet community to do so.

I don't think we disagree - the question is whether CAA is rich enough
to cover everything a UA might need. I think it might be, Phillip is
less certain.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 08:02:08 -0800

>mis-issue impossible but it does increase the risk of consequences in

I fully agree with this split of functions, and think that the access control part is appropriate to discuss on the keyassure list. The accountability control part is quite outside the scope of this mailing list, but interacts with the access control parts in this document.

I understand from second-hand sources that the accountability control part is being discussed on a closed list in the CA/Browser Forum. Is there a chance that that discussion could happen on an open list? I don't know if the CABForum folks sponsor open lists; if not, maybe Comodo or Google could set one up.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 11:06:16 -0500

I am very confident that the extension mechanism is rich enough to
support anything that we might need.

What I am less confident of is that the two properties defined at the
moment will support everything that people might want.

And the reason I want to try to avoid arguing over this is that I
think that the issue will be very quickly decided by actual
implementation experience.

At this point we have a mechanism that is perfectly adequate for
enforcing the following restrictions at the RP level:

* Must use EV.
* Must have cert issued under a particular CA.

These are actually sufficient for all the key assurance requirements I
have seen here thus far, provided that people who want to do
self-assurance and have larger than minimal needs are willing to
establish a CA root and issue certs under that rather than using
self-signed end-entity certs.

Now in my opinion, that is exactly how people should be advised to
manage self-assurance. There are a few side constraints that we may
have to address however.

For example, consider the case where a site wants to use EV certs for
HTTPS but self-asserted certs for SMTP, POP and IMAP. We might get
into a requirement for protocol specific assertions and addressing
that requirement would require a second RR assignment.

I can see possible justification for such requirements and I can see
reasons for not wanting to make the spec more complex than at present.
Rather than argue the point, I want data from deployment experience.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 12:20:36 -0500

I can raise this when we discuss the draft at the next con call.

But I really don't expect to have a great deal of substantive
discussion in CAB-Forum until after the technical spec is done. And
the type of discussion that there would be would most likely be legal
rather than technical.

If there are technical requirements that are raised in those
discussions, they would need to be brought to the IETF for action.

But again, we are at this point discussing an EXPERIMENTAL proposal
and the point of the experiment is to see if the scheme is complete.

We can of course ask CABForum to set up a list as you suggest, but I
would see a better solution to be to direct discussion of this
proposal to an IETF list, either this one or some other to be created.

But I don't think we need to get into that consideration now since
this is not yet a standards track proposal. And one of the reasons I
want to do Experimental ahead of starting the standards track is
because this is an accountability mechanism and the IETF has no
ability to impose consequences on CAs.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 7 Dec 2010 12:21:11 -0500 (EST)

> self-signed end-entity certs.

I am concerned about specifing the EV cert. I have no objection to it, but
I'm afraid it will reduce the validity of non-EV certs. That is, we might
be moving the problem from the popup of "warning: this is an untrusted
cert" to a popup of "warning: this cert is not EV". Getting keys/certs
trusted without popups and CA's was one of the goals of KEYASSURE.

Since EV-certs are much more expensive then most domains itself, this
is a significant cost problem for large scale deployments, and I would
rather see a proposal from the IETF that is purely based on technical
merits, instead of cutting of the financially poor or enforce via a legal
system to back up a tecnical one.

I understand this is client policy, but often we have no choice on those
platforms with those clients (Windows, iphone, etc)

Assuming one of the drafst for certifying keys via DNSSEC without any
CA makes it to RFC, it would be counter-productive if such new RRTYPE's
are doomed to failure because this CAA RRTYPE is missing from most zones.

Is there some phrasing that can be added that local policy MUST NOT cause any of
these issues in the future? I understand this might be hard to phrase. An
extra green bar (or lack thereof) might be okay, but a popup claiming this
might be a rogue CA is not.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 12:38:20 -0500

The purpose of this proposal is to allow sites to express certain
aspects of their security policy to issuers and relying parties.
Always use EV was a frequently cited use case.

The purpose of EV certificates is to establish accountability.

DV certificates do not establish accountability.

There is a competitive market for both types of certificate, they
serve different purposes.

Given that this proposal already crosses the DNS and Security areas, I
really do not want to get too far into a discussion that is relevant
to application design.

My view on popup boxes is that they represent a failure on the part of
the designer. they are always a cop-out. But I have spent several
years discussing that problem with other members of this list in
another place and I would prefer not to open up that particular rat
hole in this particular forum.

The way that I see it, a browser should accept any certificate
whatsoever without complaint. But it should only ever indicate to the
user that they are secure if the certificate demonstrates that there
is accountability. And it should only indicate that there is an error
if there was a reason to believe that TLS should have been used.

So the way I see it, this is an issue that can be addressed if we look
at security policy and 'must use tls'. But that goes beyond the
requirements and use cases we discussed when designing the CAA spec.

I have a presentation on this side of things on YouTube that I made
for the WebSec group.

http://www.youtube.com/user/hallambaker#p/u/0/2zmJCfUx6Uc

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 09:38:21 -0800

At 12:20 PM -0500 12/7/10, Phillip Hallam-Baker wrote:
>discussion in CAB-Forum until after the technical spec is done.

This deeply concerns me. The technical spec seems to have a lot of accountability assumptions in it that would affect both CAs and browser vendors.

>And

Those seem pretty relevant to the accountability assumptions.

>discussions, they would need to be brought to the IETF for action.

To the IETF? Were you meaning for this to be an IETF consensus document?

>and the point of the experiment is to see if the scheme is complete.

That is a terribly limited view of what an experiment might yield. Another likely result would be to see if the scheme's semantics are what the community wants. Another would be whether the document is understandable. It seems premature to limit the possible results to "complete" or not.

>proposal to an IETF list, either this one or some other to be created.

If this is meant to be an IETF activity, that makes sense. If it is meant to be an independent submission, it would not, but that's why I suggested that either Comodo or Google could set up such a list.

>ability to impose consequences on CAs.

Then why publish the accountability part in an RFC at all? I'm completely confused by the authors' intentions. Can you three clarify?

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Dec 2010 09:41:54 -0800

> system to back up a tecnical one.

Really stupid question:
How is "Must use EV" really different from "Must have cert issued under one of a particular set of CAs"?

Don't most EV certs use different roots than normal certs for the given CAs?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 7 Dec 2010 13:03:13 -0500 (EST)

On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:

> is accountability.

The key word is "accountability". You and I have very different views on
that, coming from very different worlds. And so will many implementers of
the CAA record type.

My concern is exactly the misuse of the CAA record effectively blocking
a DNSSEC-only concept of accountability, and a re-introduction of a
mandatory for-pay CA chain to securely "account" for domain names.

Paul

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 7 Dec 2010 10:11:55 -0800

> that they are interested in field trials.

If UAs aren't expected to do anything with CAA, then I as UA author
have no feedback on CAA beyond "this does not solve any problem we
care about", and won't be participating in field trials.

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 13:15:51 -0500

There are some companies that have a company wide policy that all
certs must be EV but do not currently have a single vendor or
restricted vendor policy in place for certs.

Once issued, a cert is valid for several years. I doubt that companies
would want to force reissue of every cert to perform trials. Telling
RPs that all your existing certs are EV is much easier than going
round policing every server.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 13:31:15 -0500

> care about", and won't be participating in field trials.

CAA is designed to support client enforcement and will thus require UA
behavior.

But that is going to require input and buy in from more than just one
browser provider if there is going to be a common standard. The point
of making this proposal is to start a conversation as to what the UA
implications should be and which forums it would be appropriate to
discuss them in.

My view is that WebSec would be better suited for that form of
discussion since they are apps layer concerns.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 13:39:52 -0500

> that, coming from very different worlds. And so will many implementers of

Accountability controls are based on the principle of deterrence: the
expectation that unauthorized actions may result in consequences.

I think this is a reasonably objective principle.

EV describes a set of process requirements designed to establish one
form of accountability. CAA is designed to allow a practically
infinite number of such process requirements to be defined if
necessary.

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 7 Dec 2010 10:42:07 -0800

> discussion since they are apps layer concerns.

I'd be very glad to have that conversation.  This is the venue I know
about, though.  Where's "WebSec"?

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 14:22:38 -0500

WEBSEC is an IETF working group

http://tools.ietf.org/wg/websec/charters

Here is the presentation I made to that group for the Beijing meeting
which might help set context:
http://www.youtube.com/watch?v=2zmJCfUx6Uc

We have something of a problem here with a set of concerns that cut
right across the protocol stack from transport up to application and
beyond.

While some people say 'I don't want to do X here' when they mean 'I
don't want to do X at all', I mean exactly what I say. If I think
something is a bad idea, I come right out and say it. If I say we
should do something in another place then that is precisely what I
mean as well.

The requirements for Web UA are not the same as the requirements for mail UA.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Dec 2010 14:39:12 -0500

When discussing the best approach to bringing security policy work
into IETF process with the Security Area director, he suggested that
the best approach would be to submit an Experimental proposal and see
if we can demonstrate the viability of the proposal first.

We are currently following that advice, but the long term objective is
clearly to make a consensus proposal when the ADs are willing to let
me do so.

Clearly any proposal that has far reaching effects across the industry
will involve discussions that are outside the scope of IETF.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 11:59:24 -0800

>if we can demonstrate the viability of the proposal first.

You keep speaking for that AD, and he never speaks for himself. That's bad. (And, yes, I have asked him, more than once, to speak for himself on the list.)

There is no such thing as an "Experimental proposal" in the IETF. You might have misunderstood what he said.

There are Experimental RFCs. Those can be published in the IETF stream (after getting IETF consensus) or by the Independent Submissions Editor. (We will assume for the moment that this is not an IAB or IRTF document.)

Which of those two streams are intending with this document? If it is the former, then it is appropriate to ask that AD for a mailing list for this document. If it is the latter, you do not need to discuss this on any IETF mailing list, and it is up to the ISE whether or not whatever you hand him is ready to be published.

>clearly to make a consensus proposal when the ADs are willing to let

Is the short term objective to have an Experimental RFC coming through the ISE?

>will involve discussions that are outside the scope of IETF.

Indeed. The more of those discussions that can happen on open mailing lists, the better.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Dec 2010 10:45:01 +0000

> trusted without popups and CA's was one of the goals of KEYASSURE.

Don't shoot the messenger. Is it possible to specify a mechanism that
_cannot_ lead to this outcome? I suspect not.

It is up to implementations to decide what they want to tell users
about certs. Certainly I won't be advocating the UI you suggest in any
implementation I have anything to do with.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Dec 2010 10:48:33 +0000

> Don't most EV certs use different roots than normal certs for the given CAs?

Presumably. Not sure what you're getting at here?

Clearly "must use EV" is different from "must use CA X" (where, say, X
doesn't issue EV certs) in that the certs are ... EV certs. In terms
of how you express them as CAA RRs they probably look exceedingly
similar.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 8 Dec 2010 08:33:22 -0500

> Clearly "must use EV" is different from "must use CA X" (where, say, X
doesn't issue EV certs) in that the certs are ... EV certs. In terms of
how you
> express them as CAA RRs they probably look exceedingly similar.

How does the "must use EV" feature work?  I am assuming this is derived
from the policy property mechanism but relying party usage of that
mechanism is not clear to me.  Section 2.1 provides the following
example:

   In the following example, certificates must not be issued except
   under the Default Deny Security 'Example 1' Certificate Policy and
   Relying Party Applications MAY reject certificates presented that do
   not comply with this requirement:

   $ORIGIN example.com
   .       CAA 3 policy 1.3.6.1.4.1.35405.666.1

Section 3.1.2 states the following:

   The Certificate that is issued MAY incorporate the specified policy
   OID itself but is not required to provided that the issue of the
   certificate is consistent with the requirements of the specified
   policy.

Since there is no requirement for the policy to be included in the
certificate, what should a relying party use to do this enforcement?

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Dec 2010 13:41:59 +0000

> certificate, what should a relying party use to do this enforcement?

Good point. I guess we should change that to a MUST.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 08:55:32 -0500

The browsers already have the logic an data required to recognize and enforce this.

If bogocert is trusted in the browser, and issues a cert with the Comodo EV oid, it will not be recognized as EV.

The prcise mechanisms are comlex and convoluted due to the accumulation of 15 years of barnacles and othe cruft. But they do exist. Thus it is practical to enforce this specific policy in the client, but possibly not others.

Note that a CA does not need to belong to CABrowser forum to issue EV certs, that is an issue with the auditors and coders of RP apps.

Sent from my iPad

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 8 Dec 2010 09:44:15 -0500

> The browsers already have the logic an data required to recognize and
enforce this.

The browsers do not have the logic to enforce the policy property
mechanism, which as currently written is not really enforceable (the
addition of a MUST on the issuance side that Ben suggested would fix
this).  

> If bogocert is trusted in the browser, and issues a cert with the
Comodo EV oid, it will not be recognized as EV.

You are discussing trust anchor issues that should be in this draft if
enabling "must be EV" is a goal.  

> The prcise mechanisms are comlex and convoluted due to the
accumulation of 15 years of barnacles and othe cruft. But they do exist.
Thus it is practical 
> to enforce this specific policy in the client, but possibly not
others.

Including a reference would be helpful.

> Note that a CA does not need to belong to CABrowser forum to issue EV
certs, that is an issue with the auditors and coders of RP apps.

It'd be nice if this mechanism were coupled with trust anchor
constraints to enable folks to assert EV compliance for their own CAs,
which could address the concern Paul Wouters previously stated.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 10:50:23 -0500

OK, how about the following:

1) If the policy property is marked for issue, an issuer is entitled
to issue any certificate that is consistent with that policy.

2) If marked for client enforcement, the certificate must either
contain the specified OID or know it to be consistent with the
specified OID by other means.

My preference would be to use the path property for client
enforcement. But 'must use EV' is an important subset.

If people really want to dig, it is not difficult to throw up corner
cases on the client enforcement side. My belief is that it is going to
be relatively easy to deal with these in practice because there is no
particular value in a lot of the complexity that has arisen, people
just do things in different ways because there was no particular
reason not to.

Deployment of CAA will cause issuers to look to rationalize their
activities which will in turn make the client enforcement side much
easier to deal with.

Unfortunately, a great deal of the complexity here is lore rather
something that is written down in one place. As a CA, I am only really
aware of the lore that affects my products. And I am pretty sure that
my competitors don't want me to understand the issues that might arise
from their lore.

So the traditional way we deal with this is to put a proposal on the
table and see who squawks. Then we adjust the proposal until everyone
can live with it.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 8 Dec 2010 12:15:56 -0500

> 1) If the policy property is marked for issue, an issuer is entitled
to issue any
> certificate that is consistent with that policy.

Why is it important to allow the CA to assert a different policy than
the client requested?  
 
> 2) If marked for client enforcement, the certificate must either
contain the
> specified OID or know it to be consistent with the specified OID by
other
> means.

I do not understand what this buys the relying party.    
 
> My preference would be to use the path property for client
enforcement.
> But 'must use EV' is an important subset.

If you don't want to enforce policy on the relying party, don't.  At
present, there's an example for doing this.
 
> If people really want to dig, it is not difficult to throw up corner
cases on the
> client enforcement side. My belief is that it is going to be
relatively easy to
> deal with these in practice because there is no particular value in a
lot of the
> complexity that has arisen, people just do things in different ways
because
> there was no particular reason not to.
>
activities
> which will in turn make the client enforcement side much easier to
deal with.

I think this implies an answer to my question above.  Maybe there's some
way to address composite EV/OV/DV usage during this rationalization
process.
 
> Unfortunately, a great deal of the complexity here is lore rather
something
> that is written down in one place. As a CA, I am only really aware of
the lore
> that affects my products. And I am pretty sure that my competitors
don't
> want me to understand the issues that might arise from their lore.

No need to propagate reliance on lore.  This doesn't seem particularly
complicated.  There are a set of policy identifiers that indicate EV.
An application must recognize these policies, use a trust anchor store
with a set of trust anchors authorized for these policies and validate
server certs to this trust anchor store to ensure it is valid under an
EV policy.  This spec provides pre-issuance processing (and possibly
some additional relying party checks), RFC 5280 and RFC 5937 define path
processing from TA through server certificate.
 
> So the traditional way we deal with this is to put a proposal on the
table and
> see who squawks. Then we adjust the proposal until everyone can live
with
> it.

Fair enough.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 13:06:35 -0500

I don't want to propagate reliance on lore, but I do want the exit
strategy to be as painless as possible.

In steady state this should be pretty easy to maintain. And I think
that we will naturally move to making the binding more specific over
time. But having gone through similar transitions, I do not want to
push for something that ends up being too strict.

My preference would to be to do RP enforcement on the basis of certs
or keys. Getting to the point where that is practical may require
building additional support infrastructure such as maintenance
protocols. But that is not something that should be in the critical
path here.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 8 Dec 2010 13:12:24 -0500

Why is it impractical for the CA to issue a certificate with the requested policy?  It should be no harder to get the policy right than it is to get the CA key right.  You could simply read the policies from the CA certificate and avoid requesting a policy that the CA can't issue.  

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 1:07 PM
> To: Carl Wallace
> Cc: Ben Laurie; Nicholas Weaver; [email-masked]; PaulHoffman
> Subject: Re: [keyassure] Revised version of CAA
> 
> I don't want to propagate reliance on lore, but I do want the exit strategy to
> be as painless as possible.
> 
> In steady state this should be pretty easy to maintain. And I think that we will
> naturally move to making the binding more specific over time. But having
> gone through similar transitions, I do not want to push for something that
> ends up being too strict.
> 
> My preference would to be to do RP enforcement on the basis of certs or
> keys. Getting to the point where that is practical may require building
> additional support infrastructure such as maintenance protocols. But that is
> not something that should be in the critical path here.
> 
> 
> > I think this implies an answer to my question above.  Maybe there's
> > some way to address composite EV/OV/DV usage during this
> > rationalization process.
> >
> > some additional relying party checks), RFC 5280 and RFC 5937 define
> > path processing from TA through server certificate.
> >

---

From: Jay Daley <[email-masked]>
Date: Wed, 8 Dec 2010 18:05:02 -0500

> http://tools.ietf.org/html/draft-hallambaker-donotissue-01

Some comments in no particular order:

1.  This would be better as a pointer to where the policy can be found rather than the contents of the policy itself, because:
- the policy specification can be changed independently of the RR spec, thereby reducing the frequency of changes to the RR
- it puts an upper boundary on the amount of data added to the DNS for any specific host

 (As an aside, a standardised protocol for pulling policy would be very useful in a number of places).  

2.  Given that this list is discussing keys in DNS, shouldn't this draft be wider than just CAs and include policy relating to keys in DNS?

3.  This bit seems particularly scary:

> Since the policy is published at
>    the Public Delegation Point, the policy applies to all subordinate
>    domains under example.com.

where a 'Public Delegation Point' is defined by:

>    Public Delegation Point  A Domain Name that is obtained from a public
>       DNS registry as defined by a Certification Policy.

AFAICT the first quote appears to be saying that if a CA implicitly (the implicit nature is important) defines a domain as being a 'Public Delegation Point' by virtue of including it in a list of domains for whose subdomains certificates will be issued, then this CAA record will work at all points downward. 

That means that traversing up the tree only happens if the CP implicitly allows it (i.e. by listing an acceptable parent domain in the CP), which could be different for each CA.  So you would potentially need to place multiple CAA records to cope with different CA CPs.

Also, what happens if you want to specify no certificate allowed at a delegation only domain, something many would consider?  That doesn't work if there is no CA to specify and therefore no CP to choose.  But assume for a second that this is not an issue and the CAA is respected - that would take out any certificates below that unless they too have a CAA that now allows a cert.

Or are you suggesting that the default is not to issue unless there is a CAA record, thereby taking out the whole PKIX until these are provisioned?

4.  I haven't actually found a specific "no CA allowed" but I presume that can be one by a blank/fake OID?

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Dec 2010 18:39:26 -0500

>  (As an aside, a standardised protocol for pulling policy would be very useful in a number of places).

This is not a proposal for providing machine readable policy. The
Certification Policy is typically 100+ pages of legal text.

There really is no value in pulling a CP or CPS automatically.

I do have proposals for expressing machine readable protocol security
policy, this is not such a proposal except to the extent that 'use
policy X' is itself a security policy.

> 2.  Given that this list is discussing keys in DNS, shouldn't this draft be wider than just CAs and include policy relating to keys in DNS?

As I said when I introduced this draft, some parts of the scheme are
relevant to this WG, others may not be.

> That means that traversing up the tree only happens if the CP implicitly allows it (i.e. by listing an acceptable parent domain in the CP), which could be different for each CA.  So you would poten…

Not unless you decided to deal with CAs that do not properly
understand the structure of the domains in question.

We may need to establish procedures to communicate that information
more effectively between Registries and CAs. But in general, I don't
think this has caused problems even with events like .co rebranding.

> Or are you suggesting that the default is not to issue unless there is a CAA record, thereby taking out the whole PKIX until these are provisioned?

No, a CA ignores the CAA records unless the Extended Issuer
Authorization Set is non-empty. So a site can advertise client
restrictions without CA issue restrictions (or vice-versa)

> 4.  I haven't actually found a specific "no CA allowed" but I presume that can be one by a blank/fake OID?

We can easily add a null policy if this is a real need.

Or it might be better to simply introduce a 'null' property and mark
it critical and relevant to the issuer.

---

From: Jay Daley <[email-masked]>
Date: Wed, 8 Dec 2010 23:33:20 -0500

> policy X' is itself a security policy.

That's not an answer.

> relevant to this WG, others may not be.

Neither is that.

> think this has caused problems even with events like .co rebranding.

Nor that.

> restrictions without CA issue restrictions (or vice-versa)

Then the draft should say that.

> it critical and relevant to the issuer.

Either will do.

Jay

---

From: Ben Laurie <[email-masked]>
Date: Thu, 9 Dec 2010 12:46:51 +0000

>  (As an aside, a standardised protocol for pulling policy would be very useful in a number of places).

If you are going to point at the policy then you'll need a way to
validate that the retrieved policy is indeed the one intended. A hash
of the policy in the DNS would be one way to achieve this - I am not
against the idea, but it needs to be optional.

> 2.  Given that this list is discussing keys in DNS, shouldn't this draft be wider than just CAs and include policy relating to keys in DNS?

?? It does.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 9 Dec 2010 12:48:11 +0000

> Then the draft should say that.

I am not sure why people seem to have such difficulty reading this
draft, and I welcome suggestions for alternative wording, but ...
what's wrong with:

"If the Extended Issuer Authorization Set for a domain name is not
   empty, a Certification Authority MUST NOT issue a certificate unless
   it conforms to at least one authorization entry in the Extended
   Issuer Authorization Set."

?

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Dec 2010 06:59:28 -0800

At 12:48 PM +0000 12/9/10, Ben Laurie wrote:
>draft, and I welcome suggestions for alternative wording,

I can only speak for myself, but the reason I had such difficulty reading the draft is that it mixes up CA issuing policy and end user policy but than says they are not really mixed up but then has no useful examples that show both types of policies.

Further, the emphasis on policy-by-OID is pretty foreign to most people. We can understand "if you are not WhizzyCA, don't issue a cert for me", but the idea of "even if you are WhizzyCA, don't issue a cert unless it has policy OID 1.2.457.999.33.1" seems a tad foreign. Yet that is what your examples emphasize.

> but ...

See above. Your first example is:
>   $ORIGIN example.com
>   .       CAA 1 policy 1.3.6.1.4.1.35405.666.1
That says "absolutely anyone can issue a cert for me, as long as it has this policy OID in it". That is not the type of thing most people want to say. Maybe consider putting your second example first, or even getting rid of the examples with policy OIDs altogether.

There is no example with the two things Phil says above (client restrictions with no issue restrictions, or vice versa). Adding those might help people see that you can do these two orthogonal things at the same time.

Of course, you could also just get rid of the client restrictions altogether and make your protocol cleaner. Kitchen-sink protocols in the IETF do not always work as well as we would hope.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Thu, 9 Dec 2010 15:05:35 +0000

> That says "absolutely anyone can issue a cert for me, as long as it has this policy OID in it". That is not the type of thing most people want to say. Maybe consider putting your second example fir…

As I believe I said before - I am informed (by Phil) that this is
equivalent to saying "only WhizzyCA can issue certs" and one of my
editorial comments was that we need a section to explain this.
Unfortunately it seems we managed to forget to do that, but I agree it
is confusing.

> There is no example with the two things Phil says above (client restrictions with no issue restrictions, or vice versa). Adding those might help people see that you can do these two orthogonal thin…

I agree.

> Of course, you could also just get rid of the client restrictions altogether and make your protocol cleaner. Kitchen-sink protocols in the IETF do not always work as well as we would hope.

I would not describe this as kitchen sink. If I get rid of client
restrictions from this, then where do I get my client restrictions
from?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 10:54:05 -0500

> Unfortunately it seems we managed to forget to do that, but I agree it

I am pretty sure that is how a reasonable CA would interpet the it.
But the point of security is to deal with people who are not. I can
try to make it a bit clearer.

The issue that we were trying to address with the policy approach is
that cert paths are not necessarily constant across all browsers due
to roots being resigned.

There are a bunch of cases in the US federal government PKI where the
requirement is precisely for a cert that meets the government issue
policy but does not specify the supplier. But I don't want to get into
an in depth discussion of bridge CAs.

>> There is no example with the two things Phil says above (client restrictions with no issue restrictions, or vice versa). Adding those might help people see that you can do these two orthogonal thi…

OK we can add in an example in which the issue restrictions are by
policy but the client restrictions are by cert path. I think this
would be the most common case where there would be a desire to have a
client authorization entry that is not an issuer authorization entry
(and vice versa).

>> Of course, you could also just get rid of the client restrictions altogether and make your protocol cleaner. Kitchen-sink protocols in the IETF do not always work as well as we would hope.

Kitchen sink proposals do not do well when the people presenting them
are not willing to consider the full range of issues they raise. In
this case we have been discussing designs for both purposes and have
concluded that one scheme is better than two.

> restrictions from this, then where do I get my client restrictions

I did start looking at doing these two separately. But this has a real
risk that people will start attempting to enforce records written only
for use by issuers in RPs. In particular, the fact that an Issuer is
no longer authorized does not mean that they were not properly
authorized when the cert was issued.

Looking at the management processes, it was clear that any issuer
proposal would have to have an indication of whether the records can
be used for app enforcement at the very least. As it happens Ben and I
both came to the realization independently that we could use the
unused bits in the length byte in the way we propose here.

I am very confident that this mechanism is more than capable of
allowing 99% of sites to advertise their current issue restrictions
and 90% of sites to advertise the client enforcement restrictions they
would like enforced. I am also fairly sure that if we remove either of
the properties currently specified that the coverage will be
significantly reduced.

As I keep saying, my only priority at this stage is to get a RR code
reserved so that we can start field trials.

Is there anything in the current spec that suggests that it is not
ready for trials?

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 9 Dec 2010 11:03:42 -0500

> >> That says "absolutely anyone can issue a cert for me, as long as it has this
> policy OID in it". That is not the type of thing most people want to say. Maybe
> consider putting your second example first, or even getting rid of the
> examples with policy OIDs altogether.
> >
> But the point of security is to deal with people who are not. I can try to make
> it a bit clearer.

This is very confusing.  The text you have suggested leaves open the possibility that the CA considers its own policy to meet or exceed the requested policy.  Would a CA exercising that portion of this spec be unreasonable?  You still haven't answered why a CA should be allowed to use a policy it decided is OK.
 
> 
> The issue that we were trying to address with the policy approach is that cert
> paths are not necessarily constant across all browsers due to roots being
> resigned.

What browsers are enforcing policies that are expressed in trust anchors?  If there are any, how does the proposed mechanism effect that?
 
> requirement is precisely for a cert that meets the government issue policy
> but does not specify the supplier. But I don't want to get into an in depth
> discussion of bridge CAs.
> 
> >> There is no example with the two things Phil says above (client restrictions
> with no issue restrictions, or vice versa). Adding those might help people see
> that you can do these two orthogonal things at the same time.
> >
> > I agree.
> 
> OK we can add in an example in which the issue restrictions are by policy but
> the client restrictions are by cert path. I think this would be the most
> common case where there would be a desire to have a client authorization
> entry that is not an issuer authorization entry (and vice versa).
> 
> >> Of course, you could also just get rid of the client restrictions altogether
> and make your protocol cleaner. Kitchen-sink protocols in the IETF do not
> always work as well as we would hope.
> 
> Kitchen sink proposals do not do well when the people presenting them are
> not willing to consider the full range of issues they raise. In this case we have
> been discussing designs for both purposes and have concluded that one
> scheme is better than two.
> 
> 
> I did start looking at doing these two separately. But this has a real risk that
> people will start attempting to enforce records written only for use by issuers
> in RPs. In particular, the fact that an Issuer is no longer authorized does not
> mean that they were not properly authorized when the cert was issued.
> 
> Looking at the management processes, it was clear that any issuer proposal
> would have to have an indication of whether the records can be used for app
> enforcement at the very least. As it happens Ben and I both came to the
> realization independently that we could use the unused bits in the length
> byte in the way we propose here.
> 
> 
> I am very confident that this mechanism is more than capable of allowing 99%
> of sites to advertise their current issue restrictions and 90% of sites to
> advertise the client enforcement restrictions they would like enforced. I am
> also fairly sure that if we remove either of the properties currently specified
> that the coverage will be significantly reduced.
> 
> As I keep saying, my only priority at this stage is to get a RR code reserved so
> that we can start field trials.
> 
> 
> Is there anything in the current spec that suggests that it is not ready for
> trials?
> 
> 
> --

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Dec 2010 08:12:50 -0800

>restrictions from this, then where do I get my client restrictions

The standards-track protocol that this soon-to-be-WG is supposed to produce.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Dec 2010 08:14:36 -0800

>Is there anything in the current spec that suggests that it is not

The fact that so few people other than you seem to understand it?

--Paul Hoffman, Director
--VPN Consortium

---

From: Geoff Beier <[email-masked]>
Date: Thu, 9 Dec 2010 11:38:47 -0500

> an in depth discussion of bridge CAs.

I don't see where a discussion of bridge CAs is required to address
these cases. Isn't the right approach for these to have the record
identify the common policy root along with the acceptable policy?

I don't understand the case for how a record identifying a policy but
no CA has any reliable security meaning.

Geoff

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Dec 2010 11:40:22 -0500

> reserved so that we can start field trials.

I want to be perfectly clear about this, just in case it wasn't
before: you're not getting an RRTYPE code "reserved".  Under the
procedures of RFC 5395, you're getting one _assigned_.  It means that
your RRTYPE is defined for the DNS, effectively forever.

I'm not sure if this has been clear to you so far, but if you think
that dramatic changes to the RRTYPE are going to sail through later in
the event you move the resulting protocol in the EXPERIMENTAL RFC to
the standards track, then you need to think again about your strategy.
The DNS community is notoriously prickly about this.  

We have a slightly tricky situation in the case of expert assignment
for things in I-Ds.  But as a practical matter, what has happened is
that we've treated the final I-D as definitive, and done template
updates accordingly.  This is necessary, because the description
required by section E is often a link to some I-D.  It is whatever
ends up in E that is the final authority of what the RRTYPE looks
like, and I-Ds can't be treated as stable references because, in
principle, they disappear after 6 months.

Once you have an RRTYPE, however, it is hard to change it in
incompatible ways (which very nearly means "at all"), because of
deployed software.

There has occasionally been talk of allocating an "experimental use"
range, but note that 65280-65534 is already private use.  If you want
to experiment with your closest friends, you can do it without an
RRTYPE assignment.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Dec 2010 11:50:27 -0500

On Dec 9, 2010, at 10:05 AM, Ben Laurie wrote:

[ SNIP ]

> restrictions from this, then where do I get my client restrictions

We are *almost* a WG -- the last holdup was the name (it was felt that KIDNS was to close to KITTENS, and so we are going to be called (great) DANE) -- and are just waiting on the "Go" button to be pushed.

One of the primary documents is supposed to be just what you are describing (and we have set very aggressive milestones on getting it done).

The chairs have already asked Paul Hoffman and Jakob if they would be willing to author −00 of the protocol document (starting with the ideas from the three documents listed in the charter, augmented by the wide discussion that has happened since we submitted the charter) and they have agreed to do so.

W

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Dec 2010 14:24:47 -0500

> against the idea, but it needs to be optional.

I'm not sure we are talking about the same thing, probably as I was not specific enough.

My point was that we do not need to store the policy that an issuer or a UA should use (i.e. the Authorisation Entries) in DNS but solely a pointer to where it is found.  I was not talking about the CP.

Assuming you were talking about that, then I don't agree with the need for a hash - we don't provide the hash of the web page pointed to by an _http._tcp SRV record.  DNSSEC secures the pointer, secure BGP secures the route to the IP address and the policy protocol secures the transfer of the policy.

>> 2.  Given that this list is discussing keys in DNS, shouldn't this draft be wider than just CAs and include policy relating to keys in DNS?

If it doesn't then we will have two different RRs for managing the policy around certs.

Jay

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 14:32:49 -0500

The reason I used the term 'reserved' is that this is the term that
IANA have been using in the registry. If you look you will note that
Stuart's EDNS allocation is marked reserved pending the processing of
the RFC.

I really don't want to get into a debate over the terminology here though.

There are two parts to the proposal. The first is the packaging format
which I think is pretty clear. is going to be sufficient for any
eventually as specified.

Paul has proposed some modifications to that format which I am willing
to agree to for the sake of compromise, provided that nobody else has
an objection and provided that it is stipulated that my willingness to
accept a reasonable compromise does not indicate any uncertainty,
confusion or anything else other than a willingness to be reasonable.

The property entries are extensible via a tag-value mechanism plus a
criticality bit. I think that it is very clear that this is going to
be more than sufficient for the proposed use. We have survived for
almost two decades with this in X.509v3.

So yes, I understand that the minute code goes out that employs the
RR, that this is going to effectively burn it as far as any other
proposed use is concerned.

I do not believe that the 'experimental use' area is appropriate for
this particular experiment since it is an open test and involve action
by CAs and domain name owners. If we use an experimental use code we
will have to work out a transition plan which would be complex and we
have more than enough moving parts already.

In particular, these records have rather more powerful semantics than
your typical Internet trial. I want to make sure that we do not end up
causing future experiments using that range to have unexpected side
effects.

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Dec 2010 14:36:52 -0500

>   Issuer Authorization Set."

Because that says something about non-empty when I was talking about empty.  Suggested wording that appears to conform is:

"If the Extender Issuer Authorisation Set for a domain name is empty then the CA does not search any parent domain for a CAA record but continues as though no CAA record applies."

I should note that this (and PHB's statement above) implicitly contradicts the following from the draft:

>   The following example informs CAs that certificates must not be
>    issued except under the Default Deny Security 'Example 1' Certificate
>    Policy (1.3.6.1.4.1.35405.666.1).  Since the policy is published at

Jay

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 14:44:32 -0500

> My point was that we do not need to store the policy that an issuer or a UA should use (i.e. the Authorisation Entries) in DNS but solely a pointer to where it is found.  I was not talking about th…

The Authorization Entries consist of a flag byte, a tag and an ASN.1
OID, typically 10 bytes long.

This is very clearly explained in the document.

A URI reference would be considerably longer, be less stable, be
different to the existing practice in X.509 and offer no benefit that
I can see.

> Assuming you were talking about that, then I don't agree with the need for a hash - we don't provide the hash of the web page pointed to by an _http._tcp SRV record.  DNSSEC secures the pointer, se…

Secure BGP is a proposal and not an infrastructure. And attempting to
achieve anything more than preventing Denial of Service in a routing
layer solution is probably a mistake.

I do not care about end to end connectivity to IP addresses, I only
care about end-to-end connectivity to Internet endpoints identified by
DNS names. Hence with a means of assuring keys in the DNS, I don't
need the BGP layer to provide protection against anything other than
service attacks.

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Dec 2010 15:33:46 -0500

> different to the existing practice in X.509 and offer no benefit that

That again is an orthogonal answer, not answering the point I am making.  Just to reiterate, my point is two fold:

1.  The format of a CAA record as specified is likely to change far more often that one which is just a pointer.   

2.  The issue of a single CAA record  with the current format is not an issue, the potential number of them is unbounded.  To be quite clear, my objection is to putting policy about an external system into DNS.  I do not think that is what the DNS is for.

> layer solution is probably a mistake.

That is not relevant.  The point was about the RR specifying the policy it expects to find when it connects to a policy server.  Nobody seems to need that for any other service pointed to by DNS.

Jay

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Dec 2010 17:59:47 -0500

It appears that you are assuming that the purpose of this document is
something completely different to what is described in the document.
That is not the case so I do not believe that your comments are
relevant to the proposal made.

The CAA record is intended to express the semantics 'only Comodo is
authorized to issue certs for this zone' or equivalent for other
issuers. I think it rather unlikely that there would be more than two
or three CAs issuing for one domain.

If that does turn out to be an actual use case we can always define
additional property entries.

---

From: Jay Daley <[email-masked]>
Date: Thu, 9 Dec 2010 18:25:52 -0500

> relevant to the proposal made.

Reading that inconjunction with the comments below appears to indicate you are ruling out all of my comments on the basis that you disagree with my assessment in one area only - the number of CAA records that might be published under a single domain.

To remind you, the other areas discussed but still outstanding are:

- the 'null' case - (no certificate can be issued at this domain)
- the algorithm for searching up the tree, with particular reference to an empty domain and a parent with a null case
- the general principle of putting policy into the DNS

> issuers.

Which is a /policy/ statement and it is having /policy/ like this in the DNS that I am objecting to.

> I think it rather unlikely that there would be more than two

Which rather proves my point that this RR as specified could change more than a simple redirection pointer.

Jay

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Dec 2010 11:06:48 -0500

> DNS that I am objecting to.

Security policy is the alpha and omega of DNSSEC. The only application that
can possibly justify the costs of DNSSEC is security policy.

I see no value in specification by reference for values that are typically
16 bytes per entry or less. If there is such a requirement it is easy enough
to add additional entries.

CAA is only designed to describe security policy at domain level
granularity. If greater detail is required it will be necessary to use
prefix records and those will in turn require a separate RR code. Due to the
design of DNS wildcards and aliasing, it is not possible to get the results
one would desire using the asme record for both domain level statements and
those at finer granularity.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 13 Dec 2010 12:03:21 -0500

> if there was a reason to believe that TLS should have been used.

At the risk of going off topic... I hear that approach advocated a lot,
but it fundamentally breaks the semantics that people and web sites
expect of "https" URLs:

https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14

Are you prepared to solve this?

-- 
Matt