When should honest subscribers expect sudden (24 hours / 120 hours) revocations?

[Jakob Bohm]

Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
to fast revocation fall into a few categories / groups:

(I will reference the numbered items with 24 hour limit as A#, the numbered
items with 120 hour limit as B# and the numbered items in 4.9.1.2 as C#).

(Some of the numbered items A1 to C9 fall under different categories
depending on concrete circumstances).

G1. Explicit actions by the subscriber themselves (A1, A2, B4, B6):
These are triggered and timed by their own actions and are not really
unexpected or sudden.

G2. Dishonest actions by the subscriber themselves (A2, B2, B3, B4,
B5, B8):
The subscriber brought this upon themselves, no (or little) mercy.

G3. An underlying security failure in the subscriber's
systems/organization (A3, B5, B11):
These are easily explained by the actual security incident, and any
haste and recrimination goes to that incident, the certificate
revocation is a necessary action to protect the subscriber from the
effects of the security failure.

G4. Massive failure at the CA (B9, all of C):
This is typically a major situation affecting large parts of the
Internet (unless it was an unusually small CA). Global disaster
mitigation is generally initiated in such rare situations.

G5. The CAB/F changes the minimum key strength requirements in BR 6.1.5 or
6.1.6 without a transition period (B1, C3): This would typically be voted
down by a majority of CAs.

G6. The CA has second thoughts / doubts about how they validated the
information in the certificate even though that information is actually
correct (A4, B7):
This is an operational failure at the CA, and rightly justifies blame
against the CA (however it would be nice if those two BR points allowed
retroactive correction similar to A2 and C2).

G7. The CA made a technical error in the certificate (B7, C5):
Again an operational error that justifies blaming the CA.

G8. CA specific rules not required by the BRs (B10, C9):
Clearly blameable on the CA, and possibly a reason to not choose that
CA in the first place.

So absent a bad CA, I wonder where there is a rule that subscribers
should be ready to quickly replace certificates due to actions far
outside their own control.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Lee]

On 12/27/18, Jakob Bohm via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
> to fast revocation fall into a few categories / groups:

<.. snip ..>

> So absent a bad CA, I wonder where there is a rule that subscribers
> should be ready to quickly replace certificates due to actions far
> outside their own control.

My guess is all CAs have something like
https://www.digicert.com/certificate-terms/
15. Certificate Revocation. DigiCert may revoke a Certificate without
notice for the reasons stated in the CPS, including if DigiCert
reasonably believes that:
...
h. the Certificate was (i) misused, (ii) used or issued contrary to
law, the CPS, or industry standards, or (iii) used, directly or
indirectly, for illegal or fraudulent purposes, such as phishing
attacks, fraud, or the distribution of malware or other illegal or
fraudulent purposes,
i. industry standards or DigiCert’s CPS require Certificate
revocation, or revocation is necessary to protect the rights,
confidential information, operations, or reputation of DigiCert or a
third party.

An underscore in the name now (will after Jan 15? has since cabf
ballot 202 failed to pass?) violates industry standards? If so, no
notice required.

And it seems to me that if digicert doesn't revoke certs with
underscores in the name it'll adversely affect the reputation of
DigiCert, so again it looks like no notice is required. (but anything
that has "legally valid and enforceable agreement" in the text
probably requires lawyers to decide the issue & I'm not a lawyer)

Regards,
Lee

[Jakob Bohm]

On 28/12/2018 19:44, Lee wrote:
> On 12/27/18, Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
>> to fast revocation fall into a few categories / groups:
> <.. snip ..>
>> So absent a bad CA, I wonder where there is a rule that subscribers
>> should be ready to quickly replace certificates due to actions far
>> outside their own control.
>
> My guess is all CAs have something like
> https://www.digicert.com/certificate-terms/
> 15. Certificate Revocation. DigiCert may revoke a Certificate without
> notice for the reasons stated in the CPS, including if DigiCert
> reasonably believes that:
> ...
> h. the Certificate was (i) misused, (ii) used or issued contrary to
> law, the CPS, or industry standards, or (iii) used, directly or
> indirectly, for illegal or fraudulent purposes, such as phishing
> attacks, fraud, or the distribution of malware or other illegal or
> fraudulent purposes,

These were covered in the list you snipped, and shouldn't happen for an
*honest* subscriber.

> i. industry standards or DigiCert’s CPS require Certificate
> revocation, or revocation is necessary to protect the rights,
> confidential information, operations, or reputation of DigiCert or a
> third party.

This is a catch all clause covering emergencies and BR requirements.
My list that you entirely snipped breaks down the circumstances where
the BRs require revocation at short notice.

>
> An underscore in the name ...>

Please keep the underscore issue out of this thread, which is about
the general question of what kind of notice the millions of small
(and large) certificate subscribers are realistically supposed to
get when CAs change their mind about already issued certificates.

[Ryan Sleevi]

On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > My guess is all CAs have something like
> > https://www.digicert.com/certificate-terms/
> > 15. Certificate Revocation. DigiCert may revoke a Certificate without
> > notice for the reasons stated in the CPS, including if DigiCert
> > reasonably believes that:
> > ...
> > h. the Certificate was (i) misused, (ii) used or issued contrary to
> > law, the CPS, or industry standards, or (iii) used, directly or
> > indirectly, for illegal or fraudulent purposes, such as phishing
> > attacks, fraud, or the distribution of malware or other illegal or
> > fraudulent purposes,
>

> These were covered in the list you snipped, and shouldn't happen for an
> *honest* subscriber.

It does not seem like a productive discussion will emerge if the ontology
is going to be honest/dishonest participants. By setting it up with loaded
terms like that, it seems more likely that the engagement you’ll get is
your own.

That said, it’s clear you recognize that certificate holders may, at any
point, find the need for their certificates to be replaced, and whether you
fault and blame them - or their CA - for it, it does not sound like you
dispute that. So there’s likely nothing more to be said on the topic.

[Lee]

On 12/28/18, Jakob Bohm via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> On 28/12/2018 19:44, Lee wrote:

>> On 12/27/18, Jakob Bohm via dev-security-policy
>> <dev-secur...@lists.mozilla.org> wrote:
>>> Looking at the BRs, specifically BR 4.9.1, the reasons that can lead
>>> to fast revocation fall into a few categories / groups:
>> <.. snip ..>
>>> So absent a bad CA, I wonder where there is a rule that subscribers
>>> should be ready to quickly replace certificates due to actions far
>>> outside their own control.
>>
>> My guess is all CAs have something like
>> https://www.digicert.com/certificate-terms/
>> 15. Certificate Revocation. DigiCert may revoke a Certificate without
>> notice for the reasons stated in the CPS, including if DigiCert
>> reasonably believes that:
>> ...
>> h. the Certificate was (i) misused, (ii) used or issued contrary to
>> law, the CPS, or industry standards, or (iii) used, directly or
>> indirectly, for illegal or fraudulent purposes, such as phishing
>> attacks, fraud, or the distribution of malware or other illegal or
>> fraudulent purposes,
>

> These were covered in the list you snipped, and shouldn't happen for an
> *honest* subscriber.

^shrug^ seems to me that at the very least, certs with an underscore
that were issued after July 26, 2017 (announcement of cabf ballot 202
failing to pass) were issued contrary to industry standards

>> i. industry standards or DigiCert’s CPS require Certificate
>> revocation, or revocation is necessary to protect the rights,
>> confidential information, operations, or reputation of DigiCert or a
>> third party.
>

> This is a catch all clause covering emergencies and BR requirements.
> My list that you entirely snipped breaks down the circumstances where
> the BRs require revocation at short notice.
>
>>
>> An underscore in the name ...>
>
> Please keep the underscore issue out of this thread, which is about
> the general question of what kind of notice the millions of small
> (and large) certificate subscribers are realistically supposed to
> get when CAs change their mind about already issued certificates.

Enough advance notice to keep them from getting so upset they buy
their certs from someone else?

Maybe some CAs will chime in with an answer.. but my guess is that you
won't find _a_ rule somewhere; it'll be in the CA user agreement where
they're told their cert could be revoked without notice because of
events outside their control.

Regards,
Lee

[Lee]

On 12/29/18, Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> > My guess is all CAs have something like
>> > https://www.digicert.com/certificate-terms/
>> > 15. Certificate Revocation. DigiCert may revoke a Certificate without
>> > notice for the reasons stated in the CPS, including if DigiCert
>> > reasonably believes that:
>> > ...
>> > h. the Certificate was (i) misused, (ii) used or issued contrary to
>> > law, the CPS, or industry standards, or (iii) used, directly or
>> > indirectly, for illegal or fraudulent purposes, such as phishing
>> > attacks, fraud, or the distribution of malware or other illegal or
>> > fraudulent purposes,
>>

>> These were covered in the list you snipped, and shouldn't happen for an
>> *honest* subscriber.
>
>

> It does not seem like a productive discussion will emerge if the ontology
> is going to be honest/dishonest participants.

I think it's an excellent distinction. An honest subscriber won't
deliberately attempt to spread malware. But I like the idea of CAs
revoking certs for sites deliberately trying to do harm.. even tho I
get the impression that few actually revoke certs for that reason.

> By setting it up with loaded
> terms like that, it seems more likely that the engagement you’ll get is
> your own.
>
> That said, it’s clear you recognize that certificate holders may, at any
> point, find the need for their certificates to be replaced, and whether you
> fault and blame them - or their CA - for it, it does not sound like you
> dispute that. So there’s likely nothing more to be said on the topic.

I thought the question was about how much warning an _honest_ cert
holder should expect / get before their cert was revoked.

Lee

[Jakob Bohm]

On 29/12/2018 15:32, Ryan Sleevi wrote:
> On Fri, Dec 28, 2018 at 11:21 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>> My guess is all CAs have something like
>>> https://www.digicert.com/certificate-terms/
>>> 15. Certificate Revocation. DigiCert may revoke a Certificate without
>>> notice for the reasons stated in the CPS, including if DigiCert
>>> reasonably believes that:
>>> ...
>>> h. the Certificate was (i) misused, (ii) used or issued contrary to
>>> law, the CPS, or industry standards, or (iii) used, directly or
>>> indirectly, for illegal or fraudulent purposes, such as phishing
>>> attacks, fraud, or the distribution of malware or other illegal or
>>> fraudulent purposes,
>>
>> These were covered in the list you snipped, and shouldn't happen for an
>> *honest* subscriber.
>
>
> It does not seem like a productive discussion will emerge if the ontology
> is going to be honest/dishonest participants. By setting it up with loaded
> terms like that, it seems more likely that the engagement you’ll get is
> your own.
>

The term honest is a pretty simple and obvious shorthand for a
subscriber that doesn't fall under any of the rules that require
revocation because that subscriber should not be allowed to hold
a certificate of that general nature (category G2 on my list).

> That said, it’s clear you recognize that certificate holders may, at any
> point, find the need for their certificates to be replaced, and whether you
> fault and blame them - or their CA - for it, it does not sound like you
> dispute that. So there’s likely nothing more to be said on the topic.
>

In the portion of my original post that Lee snipped, I worked through
each fast revocation reason listed in the BRs and explained how that
particular reason would usually involve fair warning for the subscriber.

For example if a domain registration is allowed to expire, the CA is
required by B4 (BR 4.9.1.1, second list, item 4) to revoke quickly, but
the subscriber has had at least one year of advance notice as to the
date when the domain would expire. Thus this falls in my category G1.

If on the other hand a court of competent jurisdiction takes away a
domain name for good cause, this would constitute a dishonest
subscriber (according to the court), and thus the subscriber can
have no expectation to get additional warning when the CA revokes under
B4 (BR 4.9.1.1, second list, item 4). Thus this falls in my category G2.

The problematic situation is if a CA revokes randomly or out of pure
fiat without fair warning. In terms of this list and the CAB/F the
problem would be if the CA inclusion policies were written or changed
to create such a situation.

[Ryan Sleevi]

On Sat, Dec 29, 2018 at 10:24 AM Lee <ler...@gmail.com> wrote:

> > It does not seem like a productive discussion will emerge if the ontology
> > is going to be honest/dishonest participants.
>

> I think it's an excellent distinction. An honest subscriber won't
> deliberately attempt to spread malware. But I like the idea of CAs
> revoking certs for sites deliberately trying to do harm.. even tho I
> get the impression that few actually revoke certs for that reason.
>

It's not, because it presumes to know the ineffable in order to make a
judgement.

Beyond the simple fact that more harm is done, immediately and long term,
by revoking for 'malware' (as the example was given, as problematic as it
may be), it suggests that a site that gets compromised, or has its key
compromised, is either not an honest subscriber or 'deserves' it. It
incorrectly frames the discussion around protecting people from themselves,
which as highlighted, is not solely the goal, nor is it reasonable to
suggest 'they deserved to get compromised'.

In many cases that Jakob tried to pose as honest (and the corollary,
dishonest), might be cast across another axis of intentional and
unintentional. An honest subscriber may be unintentionally affected by a
CA, whose misissuance may have been intentional or unintentional.

And that's mostly unknownable[1].

[1] https://www.youtube.com/watch?v=PBnO9dw3n6A

[Lee]

On 12/29/18, Ryan Sleevi <ry...@sleevi.com> wrote:
> On Sat, Dec 29, 2018 at 10:24 AM Lee <ler...@gmail.com> wrote:
>
>> > It does not seem like a productive discussion will emerge if the
>> > ontology
>> > is going to be honest/dishonest participants.
>>
>> I think it's an excellent distinction. An honest subscriber won't
>> deliberately attempt to spread malware. But I like the idea of CAs
>> revoking certs for sites deliberately trying to do harm.. even tho I
>> get the impression that few actually revoke certs for that reason.
>>
>
> It's not, because it presumes to know the ineffable in order to make a
> judgement.

You've made your opinion clear in the past. You're not going to
change my mind, I'm not going to change yours, so let's not waste our
time talking past each other. OK?

Lee

[Matt Palmer]

You were the one who brought it up, and it's such a terrible idea that it
really does need to be addressed each time, lest new participants here get
the impression that somehow it isn't all that bad.

- Matt

[Peter Bowen]

On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> So absent a bad CA, I wonder where there is a rule that subscribers
> should be ready to quickly replace certificates due to actions far
> outside their own control.

Consider the following cases:

- A company grows and moves to larger office space down the street. It
turns out that the new office is in a different city even though the move
was only two blocks away. The accounting department sends the CA a move
notice so the CA sends invoices to the new address. Does this mean the CA
has to revoke all existing certificates in 5 days?
- Widget LLC is a startup with widgetco.example. They want to take
investment so they change to a C-corp and become Widget, Inc. Widget Inc
now is the registrant for widgetco.example. Does this now trigger the 5 day
rule?
- Same example as above, but the company doesn't remember to update the
domain registration. It therefore is invalid, as it points to a
non-existence entity. Does this trigger the 5 day rule?

- The IETF publishes a new RFC that "Updates: 5280
<https://tools.ietf.org/html/rfc5280>". It removes a previously valid
feature in certificates. Do all certificates using this feature need to be
revoked within 5 days?

- The IETF publishes a new RFC that "Updates: 5280
<https://tools.ietf.org/html/rfc5280>". It says it update 5280 as follows:

Old: Conforming CAs SHOULD use the UTF8String encoding for explicitText,
but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as
VisibleString or BMPString.

NeW: Conforming CAs SHOULD use the UTF8String encoding for explicitText.
VisibleString or BMPString are acceptable but less preferred alternatives.
Conforming CAs MUST NOT encode explicitText as IA5String.

Must a CA revoke all certificates that use IA5String?

- A customer has a registered domain name that has characters that current
internationalized domain name RFCs do not allow (for example xn--df-oiy.ws/✪
df.ws). A CA issues because this is a registered domain name according to
the responsible TLD registry. Must this be revoked within 5 days if the CA
notices?

- A customer has a certificate with a single domain name in the SAN which
is an internationalized domain name. The commonName attribute in the
subject contains the IDN. However the CN attribute uses U-labels while the
SAN uses A-labels. Whether this is allowed has been the subject of debate
at the CA/Browser Forum as neither BRs nor RFCs make this clear. Do any
certificates using U-labels in the CN need to be revoked?

The list can continue to go on, but I bring these up as examples of
reasonable cases that may have surprising results.

Thanks,
Peter

The list goes on, but

[Nick Lamb]

On Sat, 29 Dec 2018 16:32:46 -0800
Peter Bowen via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> Consider the following cases:
>
> - A company grows and moves to larger office space down the street.
> It turns out that the new office is in a different city even though
> the move was only two blocks away. The accounting department sends
> the CA a move notice so the CA sends invoices to the new address.
> Does this mean the CA has to revoke all existing certificates in 5
> days?

If the certificates have this now useless address in them, then sure,
they're now wrong. Leading to two questions that have awkward answers
for CAs and my present employer: What kind of idiot would put
irrelevant stuff in the certificate and pay extra to do so?

I will also note here that it's not uncommon to give a companies "legal"
address (and even other "legal" details) that have little resemblance to
reality since they were chosen for tax efficiency or to protect a
Person with Significant Control from the lawful authority of the
country in which business is actually done.

My previous employer had a whole lot of certificates which gave the
address of a law firm on a small nominally independent island, they're a
large international company and do almost no business on that island,
but they're legally incorporated there and so that's what they decided
to write on the certificates, of course no actual users check or care.

This has a useful effect in "office move" scenarios because the legal
address does not change. But if you didn't write it at all then you
wouldn't need to care either.

> - Widget LLC is a startup with widgetco.example. They want to take
> investment so they change to a C-corp and become Widget, Inc. Widget
> Inc now is the registrant for widgetco.example. Does this now trigger
> the 5 day rule?
> - Same example as above, but the company doesn't remember to update
> the domain registration. It therefore is invalid, as it points to a
> non-existence entity. Does this trigger the 5 day rule?

It would matter which of the Ten Blessed Methods was used, in some
(most?) of the Methods the legal name of the domain registrant is
irrelevant and may never be known to the CA. Where the CA is confident
of issuance only because of a relationship to the legal registrant, a
change in registrant could indeed need urgent action by somebody.

> - The IETF publishes a new RFC that "Updates: 5280
> <https://tools.ietf.org/html/rfc5280>". It removes a previously valid
> feature in certificates. Do all certificates using this feature need
> to be revoked within 5 days?
>
> - The IETF publishes a new RFC that "Updates: 5280
> <https://tools.ietf.org/html/rfc5280>". It says it update 5280 as
> follows:

The IETF is not a member organisation. All of us can and should
participate. I know all the major browser vendors have employees who
(on or off the clock) are IETF participants, and I hope that at least
some of the CAs likewise have participants. If a CA believes that their
perspective is lacking they are, of course, free to assign one or more
personnel to track relevant work and even to pay to fly people out to
the periodic physical instantiation of the IETF.

If an IETF working group is updating RFC 5280 anybody - and I mean
anybody you don't even need to do so much as subscribe to a mailing
list first - can email that working group and point out a problem like
"Oh, if you make this change it's disruptive to our business, so please
don't do that without a suitable justification".

You are very likely to be able to achieve the IETF's requirement of
"rough consensus" to avoid changes that are needlessly disruptive.

More importantly IETF changes are often flagged months or years in
advance. In reality I would expect you'd see a Mozilla routine
communication asking CAs about their preparedness for any such change
some time in advance. It's not "five days" if you had a year's warning.

> - A customer has a registered domain name that has characters that
> current internationalized domain name RFCs do not allow (for example
> xn--df-oiy.ws/✪ df.ws). A CA issues because this is a registered
> domain name according to the responsible TLD registry. Must this be
> revoked within 5 days if the CA notices?

Seems sane to me. Also seems like a foolhardy practice by the
responsible TLD registry and/or its registrars. I would definitely
suggest annoyed subscribers demand compensation from their registrar
for letting them have a bogus name unless it turns out the registrar
was talked into this despite warning what might happen.

> - A customer has a certificate with a single domain name in the SAN
> which is an internationalized domain name. The commonName attribute
> in the subject contains the IDN. However the CN attribute uses
> U-labels while the SAN uses A-labels. Whether this is allowed has
> been the subject of debate at the CA/Browser Forum as neither BRs nor
> RFCs make this clear. Do any certificates using U-labels in the CN
> need to be revoked?

Maybe. In Python they've killed off one of the stupidest places that
thought U-labels in the Common Name were a good idea in client code.
There's a long thread, in which basically I just beat people over the
head with the same fact while they splutter about tricky language and
library problems and eventually they go "Oh, right, we should just stop
worrying about any of this and just match A-labels in SANs like Nick
says". Ding. Took a few months.

Nick.

[Jakob Bohm]

Happy new year,

On 30/12/2018 01:32, Peter Bowen wrote:
>
>
> On Thu, Dec 27, 2018 at 8:43 PM Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org

> <mailto:dev-secur...@lists.mozilla.org>> wrote:
>
> So absent a bad CA, I wonder where there is a rule that subscribers
> should be ready to quickly replace certificates due to actions far
> outside their own control.
>
>

>  Consider the following cases:
>
> - A company grows and moves to larger office space down the street.  It
> turns out that the new office is in a different city even though the
> move was only two blocks away.  The accounting department sends the CA a
> move notice so the CA sends invoices to the new address.  Does this mean
> the CA has to revoke all existing certificates in 5 days?

> - Widget LLC is a startup with widgetco.example.  They want to take
> investment so they change to a C-corp and become Widget, Inc.  Widget
> Inc now is the registrant for widgetco.example. Does this now trigger
> the 5 day rule?
> - Same example as above, but the company doesn't remember to update the
> domain registration.  It therefore is invalid, as it points to a
> non-existence entity.  Does this trigger the 5 day rule?

The above 3 cases fall under my category G1: Actions of the subscriber
themselves. One could debate the details of those rules, but at least
the subscriber had a chance to know what they were doing and when.

For the 2nd and 3rd example, it is worth noting that certificates are
issued to a subscriber identity, not a whois identity, it is (for
example) perfectly normal for a domain to be registered to Example LLC,
but operated under a private arrangement by Example Inc (who can get
an OV/EV cert), meanwhile part of the domain points to a global CDN
which obtains DV certificates for the name. Same applies where
Example Inc is incorporated in Delaware, but the whois record points
to the actual company headquarters on the US west coast.

However the examples remain valid if you substitute the certificate
identity (OV/EV) for the whois identity.

>
> - The IETF publishes a new RFC that "Updates: 5280
> <https://tools.ietf.org/html/rfc5280>".  It removes a previously valid
> feature in certificates.  Do all certificates using this feature need to
> be revoked within 5 days?
>
> - The  IETF publishes a new RFC that "Updates: 5280
> <https://tools.ietf.org/html/rfc5280>".  It says it update 5280 as follows:
>

> Old: Conforming CAs SHOULD use the UTF8String encoding for explicitText,
> but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as
> VisibleString or BMPString.
>
> NeW: Conforming CAs SHOULD use the UTF8String encoding for
> explicitText.  VisibleString or BMPString are acceptable but less
> preferred alternatives.  Conforming CAs MUST NOT encode explicitText as
> IA5String.
>
> Must a CA revoke all certificates that use IA5String?
>

This are situations where the outcome of this debate should hopefully
guide how the CAB/F and Mozilla decides to establish appropriate
transition periods.

> - A customer has a registered domain name that has characters that
> current internationalized domain name RFCs do not allow (for example

> xn--df-oiy.ws/ <http://xn--df-oiy.ws/>✪df.ws <http://df.ws>).  A CA

> issues because this is a registered domain name according to the
> responsible TLD registry.  Must this be revoked within 5 days if the CA
> notices?
>

> - A customer has a certificate with a single domain name in the SAN
> which is an internationalized domain name.  The commonName attribute in
> the subject contains the IDN.  However the CN attribute uses U-labels
> while the SAN uses A-labels.  Whether this is allowed has been the
> subject of debate at the CA/Browser Forum as neither BRs nor RFCs make
> this clear.  Do any certificates using U-labels in the CN need to be
> revoked?
>

These are the kinds of situations that are currently handled badly by
the community, with some hardliners insisting on the worst possible real
world outcome citing fears of hypothetical or moral risks.

> The list can continue to go on, but I bring these up as examples of
> reasonable cases that may have surprising results.
>