Subject: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

From: [email-masked]
Date: Thu, 08 Sep 2011 10:04:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : DNS Certification Authority Authorization (CAA) Resource Record
	Author(s)       : Phillip Hallam-Baker
                          Rob Stradling
                          Ben Laurie
	Filename        : draft-ietf-pkix-caa-02.txt
	Pages           : 13
	Date            : 2011-09-08

   The Certification Authority Authorization (CAA) DNS Resource Record
   allows a DNS domain name holder to specify the certificate signing
   certificate(s) authorized to issue certificates for that domain.  CAA
   resource records allow a public Certification Authority to implement
   additional controls to reduce the risk of unintended certificate mis-
   issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-02.txt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Sep 2011 13:38:24 -0400

This rev is mostly removing the stuff the WG does not want in PKIX scope and
changing from policy OIDs and path digests to domain names.

I have marked the old issue properties plus the auth property Google uses in
Chrome as 'reserved' to stop them being re-assigned.

I have not fully speced out how to use domain names yet. Assume that the
draft says all the right things about I18N etc.

The question to consider is what attributes we might want to permit in the
data field beyond the domain name. I see the following as possible:

1) Nothing
2) Standard attributes defined by the spec
3) Non standard attributes defined by the issuer
4) A mixture of 2 and 3.

My preference is 2 with maybe leaving the door open to 4 later on.

The reason I might want to have this type of information is that it allows
the CA to support requests to restrict issue to particular policies,
particular EKUs, etc. etc. Some of those features might be something we
could eventually agree on a standard for, but quite a few are not.

Since everything in the CAA record apart from the domain name is essentially
a conversation between the customer and their chosen CA the simplest
approach is to leave this to the CA and their customer.

If conventions do emerge over time (e.g. policy=EV) that seem worth noting
then we can do a BIS version of CAA and include them.

In order to keep the door open to the latter, I would suggest that any
subfield encoding for the data field be the SMTP header format  [tag=value
(; tag=value)* ]

On Thu, Sep 8, 2011 at 1:04 PM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Public-Key Infrastructure
> (X.509) Working Group of the IETF.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

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

---

From: "Hill, Brad" <[email-masked]>
Date: Thu, 8 Sep 2011 22:42:15 -0600

Phil,

A few comments/questions.

1)  PayPal is interested in seeing an abuse reporting facility associated with CAA.  Perhaps as simple as publishing an email address to which reports of requests for issuance that are outside of CAA policy can be sent, perhaps in a format similar to ARF.  Thoughts?

2)  The CABF is strongly considering defining a well-known OID arc representing standard issuance policies (DV, OV, EV), with the specific intent of supporting CAA.   I haven't seen much discussion on this list as to the reasons issuance policy OIDs should be out of scope.   Few sites will want to pin to a single CA (for fear of mishap, blacklist, extortion, etc.) so being able to specify uniform issuance policy constraints across multiple CAs is valuable, versus having to negotiate and issue records for multiple "private channels" carried over CAA.   Can you elaborate a bit as to why this is removed?

Thanks,

Brad Hill
PayPal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, September 08, 2011 10:38 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

This rev is mostly removing the stuff the WG does not want in PKIX scope and changing from policy OIDs and path digests to domain names.

I have marked the old issue properties plus the auth property Google uses in Chrome as 'reserved' to stop them being re-assigned.

I have not fully speced out how to use domain names yet. Assume that the draft says all the right things about I18N etc.

The question to consider is what attributes we might want to permit in the data field beyond the domain name. I see the following as possible:

1) Nothing

The reason I might want to have this type of information is that it allows the CA to support requests to restrict issue to particular policies, particular EKUs, etc. etc. Some of those features might be something we could eventually agree on a standard for, but quite a few are not.

Since everything in the CAA record apart from the domain name is essentially a conversation between the customer and their chosen CA the simplest approach is to leave this to the CA and their customer.

If conventions do emerge over time (e.g. policy=EV) that seem worth noting then we can do a BIS version of CAA and include them.

In order to keep the door open to the latter, I would suggest that any subfield encoding for the data field be the SMTP header format  [tag=value (; tag=value)* ]
On Thu, Sep 8, 2011 at 1:04 PM, <[email-masked]<mailto:[email-masked]>> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

[email-masked]<mailto:[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Sep 2011 12:40:33 -0400

On Fri, Sep 9, 2011 at 12:42 AM, Hill, Brad <[email-masked]> wrote:

> Phil,****
>
> ** **
>
> A few comments/questions.  ****
>
> ** **
>
> 1)  PayPal is interested in seeing an abuse reporting facility associated
> with CAA.  Perhaps as simple as publishing an email address to which reports
> of requests for issuance that are outside of CAA policy can be sent, perhaps
> in a format similar to ARF.  Thoughts?
>

We absolutely need that as part of our response system. The current draft is
limited to the properties that there is strong consensus for already.

2)  The CABF is strongly considering defining a well-known OID arc
> representing standard issuance policies (DV, OV, EV), with the specific
> intent of supporting CAA.   I haven’t seen much discussion on this list as
> to the reasons issuance policy OIDs should be out of scope.   Few sites will
> want to pin to a single CA (for fear of mishap, blacklist, extortion, etc.)
> so being able to specify uniform issuance policy constraints across multiple
> CAs is valuable, versus having to negotiate and issue records for multiple
> “private channels” carried over CAA.   Can you elaborate a bit as to why
> this is removed?  ****
>
>
> My original preference was for the cert digest. That seems to have been
stripped out to prevent competition with DANE.

I thought that OIDs would be more acceptable to PKIX. But people argued for
ASCII text which became internationalized text and then we all found we
could agree on a domain name. A domain name has other advantages as it turns
out as it means that the CAA record can also be the 'hey, this is how you
find out how to get a cert' record.

Again, those are design possibilities, not something we have consensus on
doing right now.

Given the current situation I am much more interested in getting what we can
get agreement on out the door than trying to argue for additional features.

We have an extension mechanism so we are not foreclosing any option.

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 9 Sep 2011 20:07:09 -0600

We absolutely need that as part of our response system. The current draft is limited to the properties that there is strong consensus for already.

[Hill, Brad] I just want to clarify my ask here.  I think it is necessary to have a standardized mechanism for CAs who receive requests for issuance that are out of policy to report such.  It is not about relying parties reporting presentation of non-compliant certificates.  The former doesn't seem controversial; it's exactly within even the limited operational scope of the new draft.
Thanks,
Brad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Sep 2011 09:04:18 -0400

Ah, got you, good idea, so something like

example.com CAA 1 ereport "[email-masked]"

Scenario:

Voldemort attempts to obtain a certificate for example.com from CertsRUs
that does not comply with some aspect of the published CAA issue policy.

CertsRUs sends a report of the violation via email to [email-masked]

Now ideally this would also be able to hook up to INCH and generate an
incident report. That will take a bit more thought.

On the other hand the CA could simply send an IODEF as an attachment.

On Fri, Sep 9, 2011 at 10:07 PM, Hill, Brad <[email-masked]> wrote:

>  ****
> in a format similar to ARF.  Thoughts?****
>
> ** **
>
> We absolutely need that as part of our response system. The current draft
> is limited to the properties that there is strong consensus for already.**
> **
>
> ** **
>
> *[Hill, Brad] I just want to clarify my ask here.  I think it is necessary
> to have a standardized mechanism for CAs who receive requests for issuance
> that are out of policy to report such.  It is not about relying parties
> reporting presentation of non-compliant certificates.  The former doesn’t
> seem controversial; it’s exactly within even the limited operational scope
> of the new draft.*
>
> *Thanks,*
>
> *Brad*****
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 10 Sep 2011 10:27:24 -0400

> [Hill, Brad] I just want to clarify my ask here.  I think it is necessary to have a standardized mechanism for CAs who receive requests for issuance that are out of policy to report such.  It is not about relying parties reporting presentation of non-compliant certificates.  The former doesn’t seem controversial; it’s exactly within even the limited operational scope of the new draft.
> 
In developing the RPKI, they had a similar, but not identical, requirement.  They asked, when there is trouble, who do you call?

draft-ietf-sidr-ghostbusters-09.txt

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 10 Sep 2011 10:46:07 -0700

On Sep 10, 2011, at 6:04 AM, Phillip Hallam-Baker wrote:

> Voldemort attempts to obtain a certificate for example.com from CertsRUs that does not comply with some aspect of the published CAA issue policy.
> 
> Now ideally this would also be able to hook up to INCH and generate an incident report. That will take a bit more thought.
> 

Email, web, and IODEF/RID are good mechanisms for these types of reports. Maybe ereport should simply be a URL.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Sep 2011 13:44:10 -0400

URL might work,

How do we manage multiple reporting formats though?

Perhaps the simplest approach would be a property IODEF that takes a URL as
the parameter. If the URL is mailto then the format is email with a MIME
attachment, otherwise its RID ?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Sep 2011 14:01:40 -0400

For some reason I don't quite understand, this whole approach to security is
not something that seems to have had much respect in IETF circles.

Incident reporting is essential if there is going to be any chance to
respond to an incident. The prevailing view seems to have been that we
should make everything so secure that incidents cannot possibly occur. The
result is a system that is very hard but brittle.

On Sat, Sep 10, 2011 at 10:27 AM, Russ Housley <[email-masked]> wrote:

> In developing the RPKI, they had a similar, but not identical, requirement.
>  They asked, when there is trouble, who do you call?
>

---

From: Russ Housley <[email-masked]>
Date: Sun, 11 Sep 2011 15:34:41 -0400

No matter how perfect we are able to make IETF specifications, there will always be implementation decencies and other human errors.  These alone argue for an infrastructure to include a means of reporting incidents.  That said, I do not agree with your "very hard but brittle" as the absolute result.

Russ

On Sep 11, 2011, at 2:01 PM, Phillip Hallam-Baker wrote:

> For some reason I don't quite understand, this whole approach to security is not something that seems to have had much respect in IETF circles.
> 
> Incident reporting is essential if there is going to be any chance to respond to an incident. The prevailing view seems to have been that we should make everything so secure that incidents cannot possibly occur. The result is a system that is very hard but brittle.
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Sep 2011 07:31:40 -0700

> How do we manage multiple reporting formats though?

Make the field free text. This makes it harder to machine-parse, but the type of reporting we are talking about (someone who notices a request to issue, or issuance, from an unauthorized CA) is probably going to at least passed by a human, if not initiated by them. So free text that can have multiple URLs seems easy and effective.

> Perhaps the simplest approach would be a property IODEF that takes a URL as the parameter. If the URL is mailto then the format is email with a MIME attachment, otherwise its RID ?

That is not "simplest" because it relies on people knowing IODEF. "Simplest" would be a bare URL that someone can read and say "that looks like an email address, I'll send it there" or "that looks like a web address, let's see if I can report it there".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 12 Sep 2011 19:48:32 -0400

We really need to get away from manual processing. I really hate turning
machine readable data into vague formats.

If the report is sent in email it can have a human readable text with a
machine readable attachment.

IODEF is the format the IETF contributed to, that could be the default. Then
if someone wants to accept something else they can add a parameter after the
URL?

On Mon, Sep 12, 2011 at 10:31 AM, Paul Hoffman <[email-masked]>wrote:

> Make the field free text. This makes it harder to machine-parse, but the
> type of reporting we are talking about (someone who notices a request to
> issue, or issuance, from an unauthorized CA) is probably going to at least
> passed by a human, if not initiated by them. So free text that can have
> multiple URLs seems easy and effective.
>
> > Perhaps the simplest approach would be a property IODEF that takes a URL
> as the parameter. If the URL is mailto then the format is email with a MIME
> That is not "simplest" because it relies on people knowing IODEF.
> "Simplest" would be a bare URL that someone can read and say "that looks
> like an email address, I'll send it there" or "that looks like a web
> address, let's see if I can report it there".
>
> --Paul Hoffman
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 09:36:07 -0400

In English, the most minimal report would be

'an attempt was made at <time> to register a certificate at CA <x> for
domain example.com which violates policy specified in CAA record <whatever>
because <reason>'

The report could in addition specify the IP addresses and email addresses
employed and would likely include human contact details for followup.

On Tue, Sep 13, 2011 at 9:26 AM, <[email-masked]> wrote:

> Hi Phil,****
>
> ** **
>
> Can you tell me exactly what you are looking to include in a report and I
> can figure out how that would be done in IODEF/RID if that were to be used?
> ****
>
> ** **
>
> FYI – there are a few incident information sharing exchanges in development
> that will drive these solutions to move forward into products.****
>
> ** **
>
> Please let me know how I can assist.****
>
> ** **
>
> Best regards,****
>
> Kathleen****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Phillip Hallam-Baker
> *Sent:* Monday, September 12, 2011 7:49 PM
> *To:* Paul Hoffman
> *Cc:* PKIX
>
> *Subject:* Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt****
>
> ** **
>
> machine readable data into vague formats.****
>
> ** **
>
> machine readable attachment. ****
>
> ** **
>
> IODEF is the format the IETF contributed to, that could be the default.
> Then if someone wants to accept something else they can add a parameter
> after the URL?****
>
> ** **
>
> On Mon, Sep 12, 2011 at 10:31 AM, Paul Hoffman <[email-masked]>
> wrote:****
>
> > How do we manage multiple reporting formats though?****
>
> multiple URLs seems easy and effective.****
>
>
> attachment, otherwise its RID ?****
>
> --Paul Hoffman****
> Website: http://hallambaker.com/****
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Sep 2011 09:21:18 -0700

On Sep 12, 2011, at 4:48 PM, Phillip Hallam-Baker wrote:

> We really need to get away from manual processing.

We disagree here. Given the expected rarity of the alerts expected for CAA, manual processing is quite appropriate.

> I really hate turning machine readable data into vague formats.
> 
> If the report is sent in email it can have a human readable text with a machine readable attachment. 
> 
> IODEF is the format the IETF contributed to, that could be the default. Then if someone wants to accept something else they can add a parameter after the URL?

IODEF is very thinly implemented and poorly understood. URLs and free text are universally implemented and well understood. This WG should not hobble CAA reporting with a restriction that will make it difficult for an individual Internet user who sees that a certificate has been mis-issued to report it. Instead, the WG should support making such mis-issuance easy to report.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Sep 2011 17:40:41 +0100

You've confused me Paul...

On 09/13/2011 05:21 PM, Paul Hoffman wrote:
> This WG should not hobble CAA reporting with a restriction that will make it difficult for an individual Internet user who sees that a certificate has been mis-issued to report it. Instead, the WG should support making such mis-issuance easy to report.

Isn't CAA just meant for CAs to read and not "individual Internet
users"?

S.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Sep 2011 10:10:17 -0700

> Isn't CAA just meant for CAs to read and not "individual Internet

I don't see anything in the draft that says that. My view is that if an individual Internet user sees a mis-issued certificate, it is fine if they want to report it, but I can also see that others in the WG might think this is slipping towards relying party apps using CAA to make security decisions. If so, then I'm fine with IODEF as the reporting format; it will be interesting to see CAs learning how to use it.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Sep 2011 19:18:40 +0200 (MEST)

I'm also slightly confused.

Paul Hoffman wrote:
> 
> Phillip Hallam-Baker wrote:
> >
> We disagree here. Given the expected rarity of the alerts
> expected for CAA, manual processing is quite appropriate.

Given the scarcity of DNS RR types, defining CAA data in a fashion
that it is extensible in the future, and supporting contact information
for both, human users as well as automated reporting, seems like a
sensible idea.

I would not feel comfortable with a definition that entirely precludes
automatic processing (i.e. automatic generation of a "certificate issuance
rejected" report/mail).

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Sep 2011 18:20:22 +0100

> I don't see anything in the draft that says that. My view is that if an individual Internet user sees a mis-issued certificate, it is fine if they want to report it, but I can also see that others…

Just to be clear. I've no specific opinion of IODEF here, I
was just puzzled by the slippery slope as you noted.

Generally, I think that the less teh CAA spec does, and the
simpler it does it, the quicker it should be done, which is,
I hope, a major goal.

If reporting meant CAA taking longer, I'd leave it out. I
suspect that any CA that's gonna check CAA already knows
how to get in touch with other CAs. Reporting could in any
case be done separately, at which point it might be useful
to consider reporting from CAs and/or end users and/or
applications and with or without batching and authentication
and all the other things we could imagine. (We don't seem
to have had any *technical* issues with news of this sort
getting out;-)

S.

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Sep 2011 19:26:11 +0200 (MEST)

Paul Hoffman wrote:
> Stephen Farrell wrote:
> I don't see anything in the draft that says that.  My view is that if
> an individual Internet user sees a mis-issued certificate, it is fine
> if they want to report it, but I can also see that others in the WG
> might think this is slipping towards relying party apps using CAA to
> make security decisions. If so, then I'm fine with IODEF as the
> reporting format; it will be interesting to see CAs learning how to use it.

I think you and PHB are talking about different things.

PHB asked for contact information, where the CA that received a
request for a certificate and denied issuance based on the CAA record
should report this denial (in addition to reporting it to the requestor),
while you are talking about the opposite direction (not currently addressed
by CAA at all): who should someone contact when assuming that one has
been presented a mis-issued TLS Server certificate -- the CA, the
DNS domain owner, or both.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 16:50:11 -0400

I was quite happy to leave it at an email address.

When I get a meeting request I typically get a human readable invite plus an
ical attachment. That model is perfectly adequate AFAIC. Just instead of it
being an ical attachment it would be iodef.

The problem with human readable is that in many cases it isn't. While it is
common to assume that everyone speaks English on the net, they don't in
practice.

I have rather a lot of experience dealing with this type of incident
response in respect of phishing. The IODEF format is used amongst the people
it was designed to serve. I was very disappointed in the politics that
caused the group to be shut down.

What we are likely to end up doing as an industry is to establish some form
of communication between CAs so that we can share information on domains
subject to attack. I can't imagine that we would want to have more than one
machine readable format for incident handling.

The attack that started this whole affair was apparently an attack against a
couple of Taiwanese driver writing shops who had their code signing certs
hijacked. There is at least one government besides Iran that is attacking
the CA infrastructure and I am just as keen to shut them down as well.

On Tue, Sep 13, 2011 at 1:20 PM, Stephen Farrell
<[email-masked]>wrote:

>>>> This WG should not hobble CAA reporting with a restriction that will
>>>> make it difficult for an individual Internet user who sees that a
>>>> certificate has been mis-issued to report it. Instead, the WG should support
>>>> making such mis-issuance easy to report.
>>>>
>>>
>> I don't see anything in the draft that says that. My view is that if an
>> individual Internet user sees a mis-issued certificate, it is fine if they
>> want to report it, but I can also see that others in the WG might think this
>> is slipping towards relying party apps using CAA to make security decisions.
>> If so, then I'm fine with IODEF as the reporting format; it will be
>> interesting to see CAs learning how to use it.
>>
>
>>  ______________________________**_________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pkix<https://www.ietf.org/mailman/listinfo/pkix>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 16:57:00 -0400

I did not say that the IETF systems are brittle, in practice most of our
systems do in fact have a reporting infrastructure.

My frustration here comes from the fact that at a certain point in time the
idea of having feedback and reporting mechanisms was apparently considered
to be 'unmanly' or something. I don't think that view is very common in the
IETF any more, but the legacy it leaves is that we have a lot of reporting
and response infrastructure that is rather ad-hoc.

On Sun, Sep 11, 2011 at 3:34 PM, Russ Housley <[email-masked]> wrote:

> No matter how perfect we are able to make IETF specifications, there will
> always be implementation decencies and other human errors.  These alone
> argue for an infrastructure to include a means of reporting incidents.  That
> said, I do not agree with your "very hard but brittle" as the absolute
> result.
>
> Russ
>
>
> For some reason I don't quite understand, this whole approach to security
> is not something that seems to have had much respect in IETF circles.
>
> On Sat, Sep 10, 2011 at 10:27 AM, Russ Housley <[email-masked]>wrote:
>
>>  1)  PayPal is interested in seeing an abuse reporting facility
>> associated with CAA.  Perhaps as simple as publishing an email address to
>> which reports of requests for issuance that are outside of CAA policy can be
>> sent, perhaps in a format similar to ARF.  Thoughts?****
>> ** **
>> is limited to the properties that there is strong consensus for already.*
>> ***
>>
>> ** **
>>
>> *[Hill, Brad] I just want to clarify my ask here.  I think it is
>> necessary to have a standardized mechanism for CAs who receive requests for
>> issuance that are out of policy to report such.  It is not about relying
>> parties reporting presentation of non-compliant certificates.  The former
>> doesn’t seem controversial; it’s exactly within even the limited operational
>> scope of the new draft.*
>>
>> In developing the RPKI, they had a similar, but not identical,
>> requirement.  They asked, when there is trouble, who do you call?
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 17:05:06 -0400

In order to move ahead, I think we need to decouple the CAA draft from
getting the reporting structure defined.

In particular because the data reported is likely something that we would
want to change over time in response to changing attacks. So that is
something I suspect is better left to CABForum or whoever.

So as a format I would suggest something like:

example.com  CAA 1 report
"mailto:[email-masked]=application/iodef"

example.com  CAA 1 report "http://rid.example.com protocol=_rid._ws"

That would seem to be capable of dealing with all likely format variations.
If we need to do more we can rev the spec and declare an additional
property.

On Tue, Sep 13, 2011 at 12:17 PM, <[email-masked]> wrote:

> Thank you for the additional details, Phillip.  The information can easily
> be represented using the IODEF data model in RFC5070 as follows:****
>
> ** **
>
> The Incident Class is the top level in the schema with child classes to add
> in more details.  ****
>
> The StartTime and DetectTime are obvious fits for the representation of
> time (there is also a ReportTime and EndTime – IODEF Section 3.8).****
>
> The Contact class is an obvious fit for including contact details (IODEF
> 3.7).****
>
> The EventData class will contain a lot of the details around any incident.
>  The details mentioned below may fit well into the History class (Section
> 3.11) as they provide background as to what happened.****
>
> ** **
>
> I think the more important aspect is to trigger an automatic response (let
> people know about a compromise so they know what they should and should not
> accept/continue using).  Within the EventData class, there is the
> Expectation class with an attribute called ‘action’.  This is an enumerated
> list of actions that are expected when an incident is reported.  The list
> may need to be extended to accommodate the actions you would expect to see
> as a result of the incident.  The list below does not include this as a
> reporting requirement, but it could be very useful to get a standard
> reaction to the incident at hand.  If there was a compromise, you could use
> a RID Report message to feed out the information on the attack with actions
> that should take place as a result. Ext-action is in the data model to
> extend the actions.****
>
> ** **
>
> Since the exact fields/attribute values are not a perfect match, an extension to IODEF that includes guidance may be appropriate.  It would be good to have this type of incident tie into the incident coordination activities as a whole for organizations rather than a separate solution.****
>
> ** **
>
> ** **
>
> The rest is included for additional information in case the diagrams help.****
>
> ** **
>
> ** **
>
>    +-------------------+****
>
>    | Expectation       |****
>
>    +-------------------+****
>
>    | ENUM restriction  |<>--{0..*}--[ Description ]****
>
>    | ENUM severity     |<>--{0..1}--[ StartTime   ]****
>
>    | ENUM action       |<>--{0..1}--[ EndTime     ]****
>
>    | STRING ext-action |<>--{0..1}--[ Contact     ]****
>
>    +-------------------+****
>
> ** **
>
>                      Figure 24: The Expectation Class****
>
> ** **
>
> ** **
>
> If you wanted to go deeper in terms of what happened, the Method class is
> used (IODEF Section 3.9). The subclass of reference includes a place to put
> a URL, but this is more around what happened as opposed to policy X was
> violated, this would be a better fit to include in the History class.  If
> there is AdditionalData that needs to be structured, this calls is used to
> extend the data model (as is the RecordItem class – section 3.19.3).****
>
> ** **
>
> The category attribute in the Node class (3.16.3) does not include a CA,
> but this can also be extended.****
>
> ** **
>
> ** **
>
>    +--------------------+****
>
>    | Incident           |****
>
>    +--------------------+****
>
>    | ENUM purpose       |<>----------[ IncidentID      ]****
>
>    | STRING ext-purpose |<>--{0..1}--[ AlternativeID   ]****
>
>    | ENUM lang          |<>--{0..1}--[ RelatedActivity ]****
>
>    | ENUM restriction   |<>--{0..1}--[ DetectTime      ]****
>
>    |                    |<>--{0..1}--[ StartTime       ]****
>
>    |                    |<>--{0..1}--[ EndTime         ]****
>
>    |                    |<>----------[ ReportTime      ]****
>
>    |                    |<>--{0..*}--[ Description     ]****
>
>    |                    |<>--{1..*}--[ Assessment      ]****
>
>    |                    |<>--{0..*}--[ Method          ]****
>
>    |                    |<>--{1..*}--[ Contact         ]****
>
>    |                    |<>--{0..*}--[ EventData       ]****
>
>    |                    |<>--{0..1}--[ History         ]****
>
>    |                    |<>--{0..*}--[ AdditionalData  ]****
>
>    +--------------------+****
>
> ** **
>
>                        Figure 2: The Incident Class****
>
> ** **
>
> ** **
>
>    +------------------+****
>
>    | EventData        |****
>
>    +------------------+****
>
>    | ENUM restriction |<>--{0..*}--[ Description    ]****
>
>    |                  |<>--{0..1}--[ DetectTime     ]****
>
>    |                  |<>--{0..1}--[ StartTime      ]****
>
>    |                  |<>--{0..1}--[ EndTime        ]****
>
>    |                  |<>--{0..*}--[ Contact        ]****
>
>    |                  |<>--{0..1}--[ Assessment     ]****
>
>    |                  |<>--{0..*}--[ Method         ]****
>
>    |                  |<>--{0..*}--[ Flow           ]****
>
>    |                  |<>--{0..*}--[ Expectation    ]****
>
>    |                  |<>--{0..1}--[ Record         ]****
>
>    |                  |<>--{0..*}--[ EventData      ]****
>
>    |                  |<>--{0..*}--[ AdditionalData ]****
>
>    +------------------+****
>
> ** **
>
>                       Figure 22: The EventData Class****
>
> ** **
>
> Please let me know if you have any more questions or how I can assist!****
>
> Kathleen****
>
> ** **
>
> *From:* Phillip Hallam-Baker [mailto:[email-masked]]
> *Sent:* Tuesday, September 13, 2011 9:36 AM
> *To:* Moriarty, Kathleen
> *Cc:* [email-masked]
>
> In English, the most minimal report would be****
>
> ** **
>
> domain example.com which violates policy specified in CAA record
> <whatever> because <reason>'****
>
> ** **
>
> employed and would likely include human contact details for followup.****
>
> ** **
>
> ** **
>
> On Tue, Sep 13, 2011 at 9:26 AM, <[email-masked]> wrote:****
>
> Hi Phil,****
>
>  ****
>
> *Cc:* PKIX****

---

From: koichi sugimoto <[email-masked]>
Date: Tue, 20 Sep 2011 22:07:58 +0900

Hello Sirs,

I am Koichi Sugimoto of GlobalSign K.K.
Now our CA system has been attacked from 'Comodo Hacker'.

http://pastebin.com/u/ComodoHacker
http://twitter.com/#!/ichsunx2

It seems that we dare to prevent hacking to issuing system.
But one of our web servers (but no relation to the issuing system) was
heavely hacked,
and, the private key seems to be stolen.
The hacker threats the base of PKI system, therefore, we must not forgive him.
I think this as a kind of cyber terror, so that, some National Agency
or Government
should work against this kind of attacks.
I've talked it to a Japanese police office, but unfortunately,
Japanese National Police did not work for it,
because our hacked server is outside of Japan even if other servers in
Japan continues to be attacked.
I want to ask you following 2 issues.

1) to prevent this kind of hacks
2) to minimize the effects if some fraudulent certificates had been issued

As for 1), please teach us where to support us to arrest him or to
prevent him to attack.
As for 2), could you specify any fields in CAA to desable the
fraudulent certificates?
 - The problem is chache of revocation information. Even if the
fraudulent certificates are revoked,
   many applications works if the cache does not be refreshed.
   One idea is some switch to clear the cache of revocation
information (OCSP, CRL,..).
   for example, most browsers cache new CRLs/OCSP responses that
include latest revocation informaion,
   if the cache is cleared.

This is very very urgent!
We need your helps.

Regards,
Koichi Sugimoto.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Sep 2011 10:43:24 -0400

Koichi-san

Unfortunately CAA as presently written does not provide the capability you
are seeking. CAA is not itself a control, it is designed to provide a CA
with additional information prior to issue of a certificate and thus avoid
mis-issue. It does not as currently specified provide revocation post-issue.

Furthermore, there is a major difficulty applying any form of revocation
mechanism in the case of a nation-state level man-in-the-middle attack. Such
an adversary is capable of performing a Denial of Communication attack
against any and all channels that may be used to pull revocation
information, including:

* OCSP and CRL pull
* DNSSEC data
* CAA / DANE records

The only way that security can be afforded the end user in such
circumstances using a site specific pull technology is if the application
fails open, i.e. the user is unable to communicate. Since this is itself a
victory for the adversary in this circumstance it is not an approach that I
believe we should consider acceptable.

The only way that I can see that we can prevent the DoC attack here is to
first separate out the emergency remediation mechanism from the general
purpose remediation mechanism and then adopt a global status model that
encompasses both revocation data and security policy data.

It is not enough to publish security policy in the DNS as the DNS can and
will be blocked. The day that a major browser implements DNSSEC verification
in the client base will be the same day that Iran starts stripping out all
DNSSEC data from the internal DNS. The only way to effectively apply DNS
data to this problem is to establish a communication channel that cannot be
DoC by the adversary.

In credit card terms, we started with the list of bad cards by the till
(CRLs) then we moved to the online status model (OCSP), the final step in
the card model was to return to a limited hotlist of the riskiest cards that
was pushed out to the boxes so that it could still be checked when the
communications link was down.

In our case the two schemes can work together. I would like to see the
following approach:

1) Google, Twitter, Facebook and other parties that are identified as likely
targets publish security policy data in their DNS zone.

2) Browsers deploy a data-driven mechanism that allows security policy and
revocation data to be pushed out to the browser. The browsers may also
attempt to acquire and apply such data from the DNS.

3) Clients are deployed that have the capability to acquire the security
policy data (via a non-standard channel if necessary) and report
non-compliance.

4) In the case that an incident is detected, the browser providers push out
a data driven response, incorporating security policy data published by the
affected site(s) if it exists.

I do not care about the syntax used to express the security policy
statements provided that it is able to support this mode of use. It is
clearly helpful if the HTTP, DNS and emergency push formats all use the same
data format with minimal syntactic translations from one to another.

As for 'prevention' of this type of attack, there are two separate concerns:

1) Preventing compromise of the Web Server host itself.
2) Moving the Web Server (and all external facing hosts) out of the critical
tier in which the validation process is performed so that compromise of
those hosts does not grant issue capability.

The first is simply applying standard hardening techniques: don't put a Web
browser or any other unnecessary software on the Web server, remove all
inessential features, block access to all unused ports on the host and at
the firewall, implement verification controls to detect (and alarm)
non-compliance.

The second requires rather substantial re-architecting of the systems if it
is not already in place. They have been best practice for some time but not
a requirement and thus outside the scope of the audit unless explicitly
specified in the CPS. Discussions are underway on this point in another
place.

---

From: koichi sugimoto <[email-masked]>
Date: Wed, 21 Sep 2011 23:12:58 +0900

Thanks for the reply.

> mis-issue. It does not as currently specified provide revocation post-issue.

But can't we explain about some method that controls revocation information?
Or explain about a new RR?
Now, CABF wants to find some solution to determin the fraudulent
certificates as fast as we can.
I think CAA also extensible, as the field that client software checks.

> against any and all channels that may be used to pull revocation

But other clients can look up the correct DNS?
If the client refreshs the revocation information, then, the client
can obtain the new CRL(s)/OCSP(s),
and thus can determin the fraudulent certificates?

Regards,
Koichi Sugimoto.

2011/9/20 Phillip Hallam-Baker <[email-masked]>:
> On Tue, Sep 20, 2011 at 9:07 AM, koichi sugimoto
> <[email-masked]> wrote:
>>
>> Hello Sirs,
>>

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 09:26:16 -0400

Hi Phil,

Can you tell me exactly what you are looking to include in a report and I can figure out how that would be done in IODEF/RID if that were to be used?

FYI - there are a few incident information sharing exchanges in development that will drive these solutions to move forward into products.

Please let me know how I can assist.

Best regards,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, September 12, 2011 7:49 PM
To: Paul Hoffman
Cc: PKIX
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

We really need to get away from manual processing. I really hate turning machine readable data into vague formats.

On Mon, Sep 12, 2011 at 10:31 AM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

--Paul Hoffman

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 12:17:20 -0400

Thank you for the additional details, Phillip.  The information can easily be represented using the IODEF data model in RFC5070 as follows:

The Incident Class is the top level in the schema with child classes to add in more details.
The StartTime and DetectTime are obvious fits for the representation of time (there is also a ReportTime and EndTime - IODEF Section 3.8).
The Contact class is an obvious fit for including contact details (IODEF 3.7).
The EventData class will contain a lot of the details around any incident.  The details mentioned below may fit well into the History class (Section 3.11) as they provide background as to what happened.

I think the more important aspect is to trigger an automatic response (let people know about a compromise so they know what they should and should not accept/continue using).  Within the EventData class, there is the Expectation class with an attribute called 'action'.  This is an enumerated list of actions that are expected when an incident is reported.  The list may need to be extended to accommodate the actions you would expect to see as a result of the incident.  The list below does not include this as a reporting requirement, but it could be very useful to get a standard reaction to the incident at hand.  If there was a compromise, you could use a RID Report message to feed out the information on the attack with actions that should take place as a result. Ext-action is in the data model to extend the actions.

Since the exact fields/attribute values are not a perfect match, an extension to IODEF that includes guidance may be appropriate.  It would be good to have this type of incident tie into the incident coordination activities as a whole for organizations rather than a separate solution.

The rest is included for additional information in case the diagrams help.

   +-------------------+

   | Expectation       |

   +-------------------+

   | ENUM restriction  |<>--{0..*}--[ Description ]

   | ENUM severity     |<>--{0..1}--[ StartTime   ]

   | ENUM action       |<>--{0..1}--[ EndTime     ]

   | STRING ext-action |<>--{0..1}--[ Contact     ]

   +-------------------+

                     Figure 24: The Expectation Class

If you wanted to go deeper in terms of what happened, the Method class is used (IODEF Section 3.9). The subclass of reference includes a place to put a URL, but this is more around what happened as opposed to policy X was violated, this would be a better fit to include in the History class.  If there is AdditionalData that needs to be structured, this calls is used to extend the data model (as is the RecordItem class - section 3.19.3).

The category attribute in the Node class (3.16.3) does not include a CA, but this can also be extended.

   +--------------------+
   | Incident           |
   +--------------------+
   | ENUM purpose       |<>----------[ IncidentID      ]
   | STRING ext-purpose |<>--{0..1}--[ AlternativeID   ]
   | ENUM lang          |<>--{0..1}--[ RelatedActivity ]
   | ENUM restriction   |<>--{0..1}--[ DetectTime      ]
   |                    |<>--{0..1}--[ StartTime       ]
   |                    |<>--{0..1}--[ EndTime         ]
   |                    |<>----------[ ReportTime      ]
   |                    |<>--{0..*}--[ Description     ]
   |                    |<>--{1..*}--[ Assessment      ]
   |                    |<>--{0..*}--[ Method          ]
   |                    |<>--{1..*}--[ Contact         ]
   |                    |<>--{0..*}--[ EventData       ]
   |                    |<>--{0..1}--[ History         ]
   |                    |<>--{0..*}--[ AdditionalData  ]
   +--------------------+

                       Figure 2: The Incident Class

   +------------------+

   | EventData        |

   +------------------+

   | ENUM restriction |<>--{0..*}--[ Description    ]

   |                  |<>--{0..1}--[ DetectTime     ]

   |                  |<>--{0..1}--[ StartTime      ]

   |                  |<>--{0..1}--[ EndTime        ]

   |                  |<>--{0..*}--[ Contact        ]

   |                  |<>--{0..1}--[ Assessment     ]

   |                  |<>--{0..*}--[ Method         ]

   |                  |<>--{0..*}--[ Flow           ]

   |                  |<>--{0..*}--[ Expectation    ]

   |                  |<>--{0..1}--[ Record         ]

   |                  |<>--{0..*}--[ EventData      ]

   |                  |<>--{0..*}--[ AdditionalData ]

   +------------------+

                      Figure 22: The EventData Class

Please let me know if you have any more questions or how I can assist!
Kathleen

From: Phillip Hallam-Baker [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, September 13, 2011 9:36 AM
To: Moriarty, Kathleen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

'an attempt was made at <time> to register a certificate at CA <x> for domain example.com<http://example.com> which violates policy specified in CAA record <whatever> because <reason>'

The report could in addition specify the IP addresses and email addresses employed and would likely include human contact details for followup.

On Tue, Sep 13, 2011 at 9:26 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Phil,

Best regards,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phillip Hallam-Baker
Sent: Monday, September 12, 2011 7:49 PM
To: Paul Hoffman
Cc: PKIX

--Paul Hoffman

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 12:36:13 -0400

"IODEF is very thinly implemented and poorly understood." - FYI, this is changing.  It may not meet your initial timeframes, but I wouldn't rule it out as that would cause potential issues for incident handlers.  They would wind up needing to support many methods to receive incident information and it could become much more difficult in the end.  IODEF is currently used by a number of country-level CSIRTs, but the adopters are growing into new areas.  Ren-ISAC is building a number of tools that will help with this expansion.  Vendors are starting to pay attention as well.

-Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, September 13, 2011 12:21 PM
To: PKIX
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

--Paul Hoffman

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 13:24:20 -0400

The use case of individuals filing a report could follow a similar path to how the Anti-phishing working group handles this situation.  A web page is available for users to report an incident.  The web page formats the incident into IODEF.  IODEF can also be used to send out a list of things that have been compromised.  The APWG is one example, another would be watch lists for fraud in the financial sector.  These are really just the same use case with a different area to report for incident management.

-Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, September 13, 2011 1:10 PM
To: Stephen Farrell
Cc: PKIX
Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-02.txt

--Paul Hoffman