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-security-policy@lists.mozilla.org 
> <mailto:dev-security-policy@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.
> 


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 
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to