Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

[Ryan Sleevi via Public]

On Fri, Aug 18, 2017 at 11:14 AM, Doug Beattie 
wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sle...@google.com]
> *Sent:* Friday, August 18, 2017 10:33 AM
> *To:* Doug Beattie 
> *Cc:* CA/Browser Forum Public Discussion List ; Kirk
> Hall 
> *Subject:* Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject
> Attributes
>
>
>
> 2) The list of meta data characters is not spelled out clearly.  We say
> parenthetically meta data characters such as ‘.’, ‘‐‘, and ‘ ‘ (i.e.
> space).  I think there are 2 categories of content we need to specifically
> disallow:
>
> 2.1) Fields that consist of only meta data characters are clearly not
> allowed.  I think this is the list:  ASCII 32 - 47, 58 - 64, 91 - 96,  123
> – 126.  This is easy to specify and then audit against.
>
>
>
> I think this is a good step, but it's worth noting that these fields can
> also contain Unicode data (e.g. UTF8String), and as a result, has a variety
> of metacharacters in a variety of languages (the number of ways to
> represent a 'period / full-stop' in Unicode is... surprising). The danger
> in specifying to this extent is that we're imply that these other sets
> _are_ acceptable, but I don't believe that's the intent.
>
>
>
> Sure, so we could frame this for this specified character set as a better
> example of the fields maybe?
>

Unfortunately, just allowing specific character sets is either
unnecessarily restrictive (e.g. there should be no reason to limit the
languages here present, provided that the CA has appropriately verified) or
increasingly complex (e.g. needing to consider metacharacters in each
language).

I'm sure, if we wanted an absolute technical profile, we could go through
that exercise, since the Unicode tables do have associated data about the
context of the character (for some categories), but I suspect that, much
like NetSec requirements, it would be onerous to maintain and evolve, as
Unicode itself continues to evolve.

I realize this is, shockingly, one of the few times I'm advocating against
a programmatic solution, which is no doubt surprising. Yet this specific
issue (metacharacters) is within the bounds that I think risk-limiting
approaches would be viable and appropriate, and we can use that opportunity
to figure out what 'less than overspecifying' solutions we can do. For
example, does the issuing CA have a process in place where it reviews such
fields of issued certificates on a regular basis? Does it have a blacklist
of phrases or characters its employees have issued (historically) to help
guide? I'm sure we could evolve a process short of programmatic checks that
appropriately balances the intent and purpose with the risk :)


> Yes, harder to programmatically audit/check.  Guidance is pretty good for
> most fields, but the OU field description remains a bit open, perhaps by
> design.
>

Right, very much by design. I think this similarly goes with other
restrictions on the OU, such as the use of brandnames or other information.
Whether or not an OU is misleading, or the brand has been authorized, is
admittedly someone of a judgement call. Should a certificate be issued
where someone disagrees with the conclusion of the CA, then I think
ultimately, what the community is wanting to understand what processes the
CA had in place, were they followed, and what opportunities exist for
improvement.

Alternatively, it may be that we want to limit the attributes in
certificates to only those that can be consistently and programatically
verified. In such a case, this would mean deprecating the OU field (as no
such registries exist, and it's subscriber-reported), and ensuring that
other attributes are consistently used (much like the serialNumber
attribute of an EV certificate, or the C attribute of others - a consistent
and well-defined form)


>
>
> Or were you suggesting that, similarly to what I remarked above, we should
> restrict/eliminate the blanket provision, instead specify the additional
> fields, and their necessary content?
>
> If CAs are not using any other Subject fields, then we should probably
> disallow them.  Someone with better programming skills could certainly
> parse the CT logs looking for additional subject fields – if there are only
> a few, then why not include them and preclude all others?
>

Now that we have CT, I wholly support this :) It was not viable in 2009 or
2012, but certainly is now :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[Phillip via Public]

One of the main things that CAs do as part of their business is precisely 
helping the customer configure their server to use the product. This is only 
one of dozens of misconfiguration issues that arise.

 

DNSSEC is complex enough in itself. One of the side effects of DNSSEC is that 
it will make any and all misconfigurations in your existing DNS apparent. It is 
the DNS equivalent of a ‘lights out’ data center. This is one of the reasons 
why positioning DANE to compete with the WebPKI was an own goal. The parties 
that might have assisted in the deployment of DNSSEC and helped customers work 
through the deployment were intentionally locked out.

 

So where the CABForum documents say ‘must not issue’, what this actually means 
in practice is ‘must not issue until the CA has helped the customer get their 
act in gear’. 

 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Friday, August 18, 2017 10:02 AM
To: Gervase Markham ; CA/Browser Forum Public Discussion List 

Cc: phill...@comodo.com; Kirk Hall 
Subject: Re: [cabfpub] Two CAA questions

 

 

 

On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham via Public 
 > wrote:

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

 

Isn't that two questions? That is, can someone explain this scenario, and how 
common is it? :)

 

I think https://github.com/dns-violations/dns-violations is a useful collection 
of various ways that vendors have improperly implemented DNS and could result 
in affecting (a limited number of sites, customers of a particular DNS host / 
CDN).

 

I'm not aware of any publicly available data showing prevalence or that it is 
common, especially in the context of CA issuance, and so I would think it would 
be a wonderful contribution to the Internet community if CAs are seeing such 
issues, that they could publish information about it.

 

I know Let's Encrypt has investigated some issues, such as 
https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748 
and https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802 , 
but these are indicative of gross server misconfigurations, and so failing to 
issue a certificate is a correct response for a misconfiguration that is 
indistinguishable from an attack.

 

As CAs often remark about OCSP, the most secure solution is to fail closed when 
a service fails. Given that CAs have direct lines with the customers affected 
by such service failures - and thus, the means to remedy the issue - this does 
not seem at all an onerous request.

 

As you said, and as Phillip mentioned, this is working as intended and 
designed, and important for security, so if there is more data that can be 
shared to help understand these concerns, that'd be useful, but otherwise it 
doesn't seem necessary to change anything.

 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Out of Office

[denise.rodriguez--- via Public]

Hello Everyone,
Thank you for your message. I am currently out of the office. I will be 
returning the 28th of August.
For urgent matters, you can contact Nicole Wayland.
Regards,
Denise

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot XXX: Canonicalise formal name of the Baseline Requirements

[Ryan Sleevi via Public]

Google will endorse

On Fri, Aug 18, 2017 at 10:49 AM, Jeremy Rowley via Public <
public@cabforum.org> wrote:

> Digicert will endorse
>
> On Aug 18, 2017, at 8:46 AM, Gervase Markham via Public <
> public@cabforum.org> wrote:
>
> [Can I get two endorsers for this administrative ballot? -- Gerv]
>
> *Ballot XXX: Canonicalise formal name of the Baseline Requirements*
>
> Purpose of Ballot: to make the formal name of the Baseline Requirements
> document clear, as use is not currently consistent.
>
> The following motion has been proposed by Gervase Markham of Mozilla and
> endorsed by XXX of XXX and XXX of XXX:
>
> *-- MOTION BEGINS --*
>
> The official name of the Baseline Requirements document shall be 'The
> Baseline Requirements for the Issuance and Management of Publicly-Trusted
> Certificates'. Approved abbreviations for official use are "the Baseline
> Requirements", and "the BRs".
>
> Editors and maintainers of CAB Forum documents and websites are empowered
> to update text under their control at any time to make this so.
>
> *-- MOTION ENDS --*
>
> The procedure for approval of this ballot is as follows:
>
>
> Start time (22:00 UTC)
>
> End time (22:00 UTC)
>
> Discussion (7 to 14 days)
>
> XXX
>
> XXX
>
> Vote for approval (7 days)
>
> XXX
>
> XXX
>
>
>
> Votes must be cast by posting an on-list reply to this thread on the
> Public list. A vote in favor of the motion must indicate a clear 'yes' in
> the response. A vote against must indicate a clear 'no' in the response. A
> vote to abstain must indicate a clear 'abstain' in the response. Unclear
> responses will not be counted. The latest vote received from any
> representative of a voting member before the close of the voting period
> will be counted. Voting members are listed here:
> https://cabforum.org/members/
> In order for the motion to be adopted, two thirds or more of the votes
> cast by members in the CA category and greater than 50% of the votes cast
> by members in the browser category must be in favor. Quorum is shown on
> CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
> number must participate in the ballot for the ballot to be valid, either by
> voting in favor, voting against, or abstaining.
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Ballot XXX: Canonicalise formal name of the Baseline Requirements

[Gervase Markham via Public]

[Can I get two endorsers for this administrative ballot? -- Gerv]

*Ballot XXX: Canonicalise formal name of the Baseline Requirements*

Purpose of Ballot: to make the formal name of the Baseline Requirements
document clear, as use is not currently consistent.

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by XXX of XXX and XXX of XXX:

*-- MOTION BEGINS --*

The official name of the Baseline Requirements document shall be 'The
Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates'. Approved abbreviations for official use
are "the Baseline Requirements", and "the BRs".

Editors and maintainers of CAB Forum documents and websites are
empowered to update text under their control at any time to make this so.

*-- MOTION ENDS --*

The procedure for approval of this ballot is as follows:




Start time (22:00 UTC)



End time (22:00 UTC)

Discussion (7 to 14 days)



XXX



XXX

Vote for approval (7 days)



XXX



XXX





Votes must be cast by posting an on-list reply to this thread on the
Public list. A vote in favor of the motion must indicate a clear 'yes'
in the response. A vote against must indicate a clear 'no' in the
response. A vote to abstain must indicate a clear 'abstain' in the
response. Unclear responses will not be counted. The latest vote
received from any representative of a voting member before the close of
the voting period will be counted. Voting members are listed here:
https://cabforum.org/members/

In order for the motion to be adopted, two thirds or more of the votes
cast by members in the CA category and greater than 50% of the votes
cast by members in the browser category must be in favor. Quorum is
shown on CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the
required quorum number must participate in the ballot for the ballot to
be valid, either by voting in favor, voting against, or abstaining.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

[Ryan Sleevi via Public]

On Fri, Aug 18, 2017 at 10:25 AM, Doug Beattie 
wrote:

> Hi Kirk and Ryan,
>
>
>
> I think this points out a couple of important changes we should make to
> the BRs:
>
>
>
> 1) We should clarify which fields can’t have just meta data characters.
> The statement is currently ambiguous in 2 ways:
>
> 1.1) It’s listed under “Other Subject Attributes” which implies it’s OK in
> any other field (which we know is not accurate).  This applies especially
> to the OU field that is listed above and then seems to be precluded from
> this requirement.
>
1.2) It’s not just optional fields, it should be ANY field in the subject
> DN. Although, all required fields should have clear requirements on what
> they MUST contain, it would not hurt to apply this meta data requirement to
> all Subject information fields.
>

Wholeheartedly agree :) This is consistent with the spirit and intent, and
is an unnecessary ambiguity :)


> 2) The list of meta data characters is not spelled out clearly.  We say
> parenthetically meta data characters such as ‘.’, ‘‐‘, and ‘ ‘ (i.e.
> space).  I think there are 2 categories of content we need to specifically
> disallow:
>
> 2.1) Fields that consist of only meta data characters are clearly not
> allowed.  I think this is the list:  ASCII 32 - 47, 58 - 64, 91 - 96,  123
> – 126.  This is easy to specify and then audit against.
>

I think this is a good step, but it's worth noting that these fields can
also contain Unicode data (e.g. UTF8String), and as a result, has a variety
of metacharacters in a variety of languages (the number of ways to
represent a 'period / full-stop' in Unicode is... surprising). The danger
in specifying to this extent is that we're imply that these other sets
_are_ acceptable, but I don't believe that's the intent.

Of course, this itself is a symptom of allowing CAs arbitrary flexibility
for additional attributes. It would be useful to know whether CAs have
availed themselves of this flexibility, as perhaps we can cut this Gordian
Knot simply by prohibiting additional fields.


> 2.1) The harder one is to say don’t put nonsense into any fields like N/A,
> NA, test, “not applicable” etc.  The descriptions of all the fields in BR
> section 7.1.4.2.2 items a-h are clear on the content.  Item i) OU and j)
> Other subject attributes, might need to more clearly specify what is
> permitted and what is prohibited.
>

Harder in what sense? I suspect you mean regarding programatic auditing,
but I wanted to make sure I'm not confusing the issue. I think that as long
as we allow CA discretion, we won't be able to solve the programatic
auditing, and so our best hope is to provide the procedural guidance.

Or were you suggesting that, similarly to what I remarked above, we should
restrict/eliminate the blanket provision, instead specify the additional
fields, and their necessary content?

>
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

[Doug Beattie via Public]

Hi Kirk and Ryan,

I think this points out a couple of important changes we should make to the BRs:

1) We should clarify which fields can’t have just meta data characters.  The 
statement is currently ambiguous in 2 ways:
1.1) It’s listed under “Other Subject Attributes” which implies it’s OK in any 
other field (which we know is not accurate).  This applies especially to the OU 
field that is listed above and then seems to be precluded from this requirement.
1.2) It’s not just optional fields, it should be ANY field in the subject DN. 
Although, all required fields should have clear requirements on what they MUST 
contain, it would not hurt to apply this meta data requirement to all Subject 
information fields.

2) The list of meta data characters is not spelled out clearly.  We say 
parenthetically meta data characters such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space).  I 
think there are 2 categories of content we need to specifically disallow:
2.1) Fields that consist of only meta data characters are clearly not allowed.  
I think this is the list:  ASCII 32 - 47, 58 - 64, 91 - 96,  123 – 126.  This 
is easy to specify and then audit against.
2.1) The harder one is to say don’t put nonsense into any fields like N/A, NA, 
test, “not applicable” etc.  The descriptions of all the fields in BR section 
7.1.4.2.2 items a-h are clear on the content.  Item i) OU and j) Other subject 
attributes, might need to more clearly specify what is permitted and what is 
prohibited.

The Validation WG should probably take this up.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, August 18, 2017 9:49 AM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

Hi Kirk,

Your email may be confusing somethings. This is related to Entrust's issuance 
of non-BR compliant certificates, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 , correct? Hopefully 
you'll have a chance to reply there, even if to only acknowledge receipt and 
that Entrust is investigating.

The short answer is this language came from the Forum, because it makes sense. 
As CAs have liked to suggest that the additional subject information afforded 
by an EV and OV certificate is meaningful, and as both the Baseline 
Requirements and the EV Guidelines exist to create a common profile of fields, 
this language prohibits a practice that was previously common, of CAs 
explicitly including certain attributes in fields and putting the contents such 
as "n/a" or "-"

This is undesirable for many reasons, which the Forum recognized when 
prohibiting.
1) One goal of our requirements is to ensure certificates from different CAs 
follow a consistent profile and representation. One CA's "n/a" could be encoded 
as another CA's "-", and one CAs "NA" could mean "not applicable" could mean 
another CA's "North America". The current requirement helps ensure consistency.
2) For optional fields, there's a defined way in X.509 (and, by proxy, RFC 
5280) to how to represent that an optional field was not applicable or not 
verified - and that's simply to not include it. There is no technical 
requirement that a CA include a subject Attribute Type with an empty or 
symbolic Attribute Value; if it's not applicable, the correct approach, in all 
the relevant standards, is to simply omit this field.
3) Omitting this field, rather than filling it with 'junk' data (such as '-', ' 
', or other indicators of no applicability) helps keep certificates smaller, 
and by doing so, ensures TLS remains accessible for a broad spectrum of users 
and site operators.
4) In particular for browsers, the contents of Subject fields are displayed. 
Even in cases where a localized name for the associated Attribute Type is not 
included in the UI (e.g. Li-Chun's remarks about the EV OIDs in the context of 
Firefox and, previously, Chrome), the Attribute Value, by being an appropriate 
universal ASN.1 type, can and is displayed. That is, in the UI, you might see 
something like "1.2.3.4: N/A" in the UI for an attribute type 
of OID 1.2.3.4 and an attribute value of IA5String. In order to ensure that UI 
behaviour is consistent, and that CAs do not introduce additional information 
that confuses or misleads relying parties, such prohibitions are useful.


As such, (j) serves a very important purpose, and while I appreciate your 
questions to understand its usage as well, would be very inappropriate to 
remove. More importantly, that suggestion seems to miss the first section of 
that requirement (j) - namely, that the content actually be verified by the CA. 
Were we to adopt your suggestion - fully removing (j) - then CAs would be fully 
permitted to introduce invalid, misleading information, which would be 
contained within the certificate and displayed to users, without violating the 
Baseline 

Re: [cabfpub] Two CAA questions

[Ryan Sleevi via Public]

On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham via Public <
public@cabforum.org> wrote:

> Is anyone able to explain why this scenario is at all common? Why would
> the authoritative nameservers for a domain refuse to answer queries, if
> the owner of the domain wanted the domain to work at all?
>

Isn't that two questions? That is, can someone explain this scenario, and
how common is it? :)

I think https://github.com/dns-violations/dns-violations is a useful
collection of various ways that vendors have improperly implemented DNS and
could result in affecting (a limited number of sites, customers of a
particular DNS host / CDN).

I'm not aware of any publicly available data showing prevalence or that it
is common, especially in the context of CA issuance, and so I would think
it would be a wonderful contribution to the Internet community if CAs are
seeing such issues, that they could publish information about it.

I know Let's Encrypt has investigated some issues, such as
https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748
and https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802
, but these are indicative of gross server misconfigurations, and so
failing to issue a certificate is a correct response for a misconfiguration
that is indistinguishable from an attack.

As CAs often remark about OCSP, the most secure solution is to fail closed
when a service fails. Given that CAs have direct lines with the customers
affected by such service failures - and thus, the means to remedy the issue
- this does not seem at all an onerous request.

As you said, and as Phillip mentioned, this is working as intended and
designed, and important for security, so if there is more data that can be
shared to help understand these concerns, that'd be useful, but otherwise
it doesn't seem necessary to change anything.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

[Ryan Sleevi via Public]

Hi Kirk,

Your email may be confusing somethings. This is related to Entrust's
issuance of non-BR compliant certificates,
https://bugzilla.mozilla.org/show_bug.cgi?id=1390996 , correct? Hopefully
you'll have a chance to reply there, even if to only acknowledge receipt
and that Entrust is investigating.

The short answer is this language came from the Forum, because it makes
sense. As CAs have liked to suggest that the additional subject information
afforded by an EV and OV certificate is meaningful, and as both the
Baseline Requirements and the EV Guidelines exist to create a common
profile of fields, this language prohibits a practice that was previously
common, of CAs explicitly including certain attributes in fields and
putting the contents such as "n/a" or "-"

This is undesirable for many reasons, which the Forum recognized when
prohibiting.
1) One goal of our requirements is to ensure certificates from different
CAs follow a consistent profile and representation. One CA's "n/a" could be
encoded as another CA's "-", and one CAs "NA" could mean "not applicable"
could mean another CA's "North America". The current requirement helps
ensure consistency.
2) For optional fields, there's a defined way in X.509 (and, by proxy, RFC
5280) to how to represent that an optional field was not applicable or not
verified - and that's simply to not include it. There is no technical
requirement that a CA include a subject Attribute Type with an empty or
symbolic Attribute Value; if it's not applicable, the correct approach, in
all the relevant standards, is to simply omit this field.
3) Omitting this field, rather than filling it with 'junk' data (such as
'-', ' ', or other indicators of no applicability) helps keep certificates
smaller, and by doing so, ensures TLS remains accessible for a broad
spectrum of users and site operators.
4) In particular for browsers, the contents of Subject fields are
displayed. Even in cases where a localized name for the associated
Attribute Type is not included in the UI (e.g. Li-Chun's remarks about the
EV OIDs in the context of Firefox and, previously, Chrome), the Attribute
Value, by being an appropriate universal ASN.1 type, can and is displayed.
That is, in the UI, you might see something like "1.2.3.4: N/A" in the UI
for an attribute type of OID 1.2.3.4 and an attribute value of IA5String.
In order to ensure that UI behaviour is consistent, and that CAs do not
introduce additional information that confuses or misleads relying parties,
such prohibitions are useful.


As such, (j) serves a very important purpose, and while I appreciate your
questions to understand its usage as well, would be very inappropriate to
remove. More importantly, that suggestion seems to miss the first section
of that requirement (j) - namely, that the content actually be verified by
the CA. Were we to adopt your suggestion - fully removing (j) - then CAs
would be fully permitted to introduce invalid, misleading information,
which would be contained within the certificate and displayed to users,
without violating the Baseline Requirements.

Even if we were to scope your request more narrowly, and remove simply that
section of (j), we would be returning to the wild west of arbitrary CA
contents, and that's undesirable.

So no, I do not believe any changes to this section are necessary, and hope
that all CA participants are reviewing their systems to ensure compliance.


On Thu, Aug 17, 2017 at 8:54 PM, Kirk Hall via Public 
wrote:

> There has been a discussion on a Mozilla list Certificates with
> Metadata-Only Subject Fields, https://groups.google.com/
> forum/#!topic/mozilla.dev.security.policy/Sae5lpT02Ng, that concerns BR 
> 7.1.4.2.2.
> Subject Distinguished Name Fields:
>
>
>
> *j. Other Subject Attributes*
>
> All other optional attributes, when present within the subject field, MUST
> contain information that has
>
> been verified by the CA. Optional attributes MUST NOT contain metadata
> such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space)
>
> characters, and/or any other indication that the value is absent,
> incomplete, or not applicable.
>
>
>
> My question to the Forum is – where did this language come from?  An RFC?
> Some other standard?  Does this prohibition actually make sense (especially
> for the OU field, which is optional but must be verified by the CA if it
> includes identity-type information)?  Can we consider deleting sub (j) or
> clarifying it only applies to certain fields?
>
>
>
> *Ballot 33 – Subject attribute requirements (4 August 2009)*
>
> Vote
>
> Yes: Entrust, VeriSign, GlobalSign, DigiCert, T-Systems, QuoVadis,
> StartCom, Buypass, Trustwave, Comodo, SSC and Microsoft.
>
> No: None.
>
> Abstain: None.
>
> Result: Accepted.
>
> Motion:
>
> Steve Roylance made the following motion, and Johnathan Nightingale and
> Jay Schiavo endorsed it:
> --
>
> Motion begins
> --
>
> The Guidelines should be amended by the 

Re: [cabfpub] Two CAA questions

[Gervase Markham via Public]

On 02/08/17 23:40, philliph--- via Public wrote:
>> We cannot, however, determine whether the "domain’s zone does not have
>> a DNSSEC validation chain to the ICANN root" because the domain's zone
>> authoritative name servers are refusing to answer our DNS queries.
>>  
>> This scenario is encountered often enough in the real world that it
>> would prevent many certificates from being issued if ballot 187 is
>> followed.

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

>> One potential solution is to allow CA's to treat REFUSED status
>> responses from authoritative name servers as permission to issue.
> 
> ​The problem with doing this is that it opens up a downgrade attack.

As PHB says, this doesn't sound like the right route.

> We know if the zone is DNSSEC signed or not (NSEC3 in the parent zone).
> REFUSED + DNSSEC should mean no certificate. ​If you turn on DNSSEC and
> much it up, then you are going to be in for a world of hurt anyways.
> That is what DNSSEC is for.

So you can determine whether the parent zone is DNSSEC-signed or not
without needing a response from the authoritative nameserver for the
domain itself? Do I have this right: if the parent zone is not signed,
clearly the domain itself won't be signed. But if the parent zone it
signed, you can't tell if the domain itself is signed or not without the
authoritative nameserver telling you.

Is that right?

Oh, and yes, an empty record means "no-one can issue".

Gerv


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Two CAA questions

[Gervase Markham via Public]

On 02/08/17 23:40, philliph--- via Public wrote:
>> We cannot, however, determine whether the "domain’s zone does not have
>> a DNSSEC validation chain to the ICANN root" because the domain's zone
>> authoritative name servers are refusing to answer our DNS queries.
>>  
>> This scenario is encountered often enough in the real world that it
>> would prevent many certificates from being issued if ballot 187 is
>> followed.

Is anyone able to explain why this scenario is at all common? Why would
the authoritative nameservers for a domain refuse to answer queries, if
the owner of the domain wanted the domain to work at all?

>> One potential solution is to allow CA's to treat REFUSED status
>> responses from authoritative name servers as permission to issue.
> 
> ​The problem with doing this is that it opens up a downgrade attack.

As PHB says, this doesn't sound like the right route.

> We know if the zone is DNSSEC signed or not (NSEC3 in the parent zone).
> REFUSED + DNSSEC should mean no certificate. ​If you turn on DNSSEC and
> much it up, then you are going to be in for a world of hurt anyways.
> That is what DNSSEC is for.

So you can determine whether the parent zone is DNSSEC-signed or not
without needing a response from the authoritative nameserver for the
domain itself? Do I have this right: if the parent zone is not signed,
clearly the domain itself won't be signed. But if the parent zone it
signed, you can't tell if the domain itself is signed or not without the
authoritative nameserver telling you.

Is that right?

Oh, and yes, an empty record means "no-one can issue".

Gerv


___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public