Re: Yet more undisclosed intermediates

[Wayne Thayer via dev-security-policy]

On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/01/2019 17:17, Wayne Thayer wrote:
> > The options to consider are:
> > 1. Continue with current policy of treating non-disclosure of
> unconstrained
> > intermediates as an incident. This could eventually lead to having the
> > offending intermediate added to OneCRL, but in practice it never has
> > because disclosure is not difficult.
>
> No comment
>
> > 2. Change our policy to state that any undisclosed intermediate we
> discover
> > will be immediately and permanently added to OneCRL.
>
> This needs adding some logical criteria, notably:
>
> - Allow the SubCA certificate itself and any related technical
>   signatures (CRL, OCSP signer, test site signatures etc.) and deeper
>   SubSubCAs to be generated and added to CT as part of the signing
>   ceremony before submission.  This of cause within the reporting
>   deadline already specified in Mozilla policy for new SubCAs.
>
> - Send a stern warning e-mail to the CA contact when 2/3 of the time
>   between SubCA generation and deadline expiry has passed.
>
> How do we know about the SubCA if it hasn't been disclosed? By the time
the SubCA appears in CT, the 1-week disclosure deadline has very likely
passed.

- Include a manual review to check for misidentification of SubCA
>   submission policy violations (such as the Izenpe case earlier today).
>
> - An exception if there was a relevant CCADB issue (downtime,
>   configuration, account problems etc.) during the CCADB submission
>   deadline.
>
> - In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
>   for this reason only.  This to allow extremely space or bandwidth
>   constrained OneCRL consumers to omit those, as well as to provide
>   truthful error messages in full clients such as Firefox.
>
> > 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
> > currently defined, this is not an enforcement mechanism for disclosure,
> but
> > it could be.
>
> Note however that there is always the issue that "intermediate
> preloading" will typically only update along the browser/mailclient
> /other software release schedule while SubCAs can be validly created and
> disclosed at any time (in practice: On the CAs root ceremony schedule).
>
> Intermediate preloading will use the same distribution mechanism as
OneCRL. Yes, there will be some delay before a new intermediate is known by
most/all clients, but the timescale is hours, not weeks.

> 4. Assume that CT enforcement will (eventually, on some undefined timeline
> > for Firefox) force intermediate disclosures and eliminate the need for
> > Mozilla to require CAs to manually disclose serverAuth intermediates in
> > CCADB.
> >
>
> CT disclosed SubCAs not in CCADB are the typical case of currently
> detected violations.  Thus CT enforcement would not fix this unless CT
> enforcement causes the CCADB disclosure rule to be removed/relaxed as
> redundant.
>
>
Yes, the idea is that CT could remove the need to enforce intermediate
disclosures via policy.

> I don't expect options 3 and 4 to be viable for S/MIME certificates
> anytime
> > soon, so different options might be chosen for TLS and S/MIME.
> >
> > I'm interested to hear if anyone has opinions on these options.
> >
>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 2, 2019 at 1:32 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > 2. Change our policy to state that any undisclosed intermediate we
> discover
> > will be immediately and permanently added to OneCRL.
>
> This needs adding some logical criteria, notably:
>

It's not clear what you feel drives these requirements. A few selected
comments below.


> - Send a stern warning e-mail to the CA contact when 2/3 of the time
>   between SubCA generation and deadline expiry has passed.
>

Could you explain why you see this being required?


> - In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
>   for this reason only.  This to allow extremely space or bandwidth
>   constrained OneCRL consumers to omit those, as well as to provide
>   truthful error messages in full clients such as Firefox.
>

This one is more interesting. There is only one OneCRL consumer, and the
question of product UI or behaviour is not really part of this Forum (note:
policy). It seems like this is working backward from a requirement - you
think there should be a different error message - and then trying to imply
how to meet that, without really clearly stating that.

Could you instead elaborate on what you see the desired end-states are,
rather than enumerating the proposed intermediate steps?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Ryan Sleevi via dev-security-policy]

On Wed, Jan 2, 2019 at 11:18 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The options to consider are:
> 1. Continue with current policy of treating non-disclosure of unconstrained
> intermediates as an incident. This could eventually lead to having the
> offending intermediate added to OneCRL, but in practice it never has
> because disclosure is not difficult.
> 2. Change our policy to state that any undisclosed intermediate we discover
> will be immediately and permanently added to OneCRL.
> 3. Wait for the "intermediate preloading" feature to ship in Firefox. As
> currently defined, this is not an enforcement mechanism for disclosure, but
> it could be.
> 4. Assume that CT enforcement will (eventually, on some undefined timeline
> for Firefox) force intermediate disclosures and eliminate the need for
> Mozilla to require CAs to manually disclose serverAuth intermediates in
> CCADB.
>

Given the timescales of intermediates (5-10 years) vs other certificates,
it's unclear how #4 would be done. I suspect that, between #3 and #4, that
#3 is probably functionally far more attractive, and operationally cleaner
for CAs (given the offline nature of intermediate signing ceremonies due to
the root key material).

I think of the first two, #2 is more appealing than #1, as it avoids the
needs to distinguish malice from operational failure, and thus provides
something clear and automatable (from the client side), thus removing the
necessity of discussion. #3 simply moves this from a "permanent" state to a
"temporary" state, which doesn't seem like it changes much for Subscribers,
but is friendlier to CAs that have operational failures.

So it sounds like a combination of #3+#1 (treating it as an incident, but
allowing for temporary blocking) may be a balanced approach if leniency for
operational mistakes are desired, otherwise, #2 seems the easiest to set
expectations and not have to litigate/renegotiate/investigate every time it
happens. #4 is just a different technical means to approaching some
variation of #3/#2, but with different tradeoffs, and less predictability
(embedded proofs vs TLS-delivered / OCSP stapled proofs)

Thus, a preference is:
#2
(combination of #3 + #1)
#4
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Wayne Thayer via dev-security-policy]

On Wed, Jan 2, 2019 at 7:10 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> > El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling
> escribió:
> >> On 09/10/2018 23:53, Wayne Thayer wrote:
> >>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
> >>>  Wayne, Kathleen:
> >>>  Given the number of times that all the CAs in Mozilla's Root
> Program
> >>>  have been reminded about Mozilla's requirements for disclosing
> >>>  intermediate certs, I wouldn't blame you if you decided to add
> these 20
> >>>  intermediate certs [5] to OneCRL immediately!
> >>>
> >>> I think we should give this serious consideration, although it doesn't
> >>> help with the majority of these that are trusted for email.
> >>
> >> Hi Wayne.  Did you give this serious consideration?
> >>
>
The options to consider are:
1. Continue with current policy of treating non-disclosure of unconstrained
intermediates as an incident. This could eventually lead to having the
offending intermediate added to OneCRL, but in practice it never has
because disclosure is not difficult.
2. Change our policy to state that any undisclosed intermediate we discover
will be immediately and permanently added to OneCRL.
3. Wait for the "intermediate preloading" feature to ship in Firefox. As
currently defined, this is not an enforcement mechanism for disclosure, but
it could be.
4. Assume that CT enforcement will (eventually, on some undefined timeline
for Firefox) force intermediate disclosures and eliminate the need for
Mozilla to require CAs to manually disclose serverAuth intermediates in
CCADB.

I don't expect options 3 and 4 to be viable for S/MIME certificates anytime
soon, so different options might be chosen for TLS and S/MIME.

I'm interested to hear if anyone has opinions on these options.

Thanks,

Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 02/01/2019 13:44, info--- via dev-security-policy wrote:
> El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling  escribió:
>> On 09/10/2018 23:53, Wayne Thayer wrote:
>>> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
>>>  Wayne, Kathleen:
>>>  Given the number of times that all the CAs in Mozilla's Root Program
>>>  have been reminded about Mozilla's requirements for disclosing
>>>  intermediate certs, I wouldn't blame you if you decided to add these 20
>>>  intermediate certs [5] to OneCRL immediately!
>>>
>>> I think we should give this serious consideration, although it doesn't
>>> help with the majority of these that are trusted for email.
>>
>> Hi Wayne.  Did you give this serious consideration?
>>
>> An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for
>> well over a month, but hasn't yet been disclosed to the CCADB.
>>
>>
>> [1] https://crt.sh/?id=966433897
>>
>> [2] https://crt.sh/mozilla-disclosures
>>
>> -- 
>> Rob Stradling
>> Senior Research & Development Scientist
>> Sectigo Limited
> 
> We're reviewing what happened with this subCA, because it's reported to the 
> CCADB (like all other subCAs). At the moment we've seen that there are two 
> different entries in the crt.sh with the same serial number, but different 
> fingerprints:
> 
> https://crt.sh/?id=1477430 -> disclosed
> https://crt.sh/?id=966433897 -> not disclosed
> 
> This CA is not new, so there wouldn’t be any problem. But we continue 
> analyzing what happened.

Thanks Oscar.  You're right: 966433897 is a duplicate of 1477430, and so 
this is *not* a violation of Mozilla's intermediate cert disclosure 
requirement.

The only difference between the two certs is the encoding of the 
signature parameters in the part of the certificate that is not covered 
by the CA's signature.  Anyone could create any number of "different" 
certs with malformed signature parameters that share the same 
CA-produced signature, and for this we can't blame the CA.  As it 
happens though, 966433897 is slightly less malformed than 1477430.

It's unfortunate that some CT logs accept, or used to accept, certs with 
malformed signature parameters (in the part of the cert not covered by 
the CA's signature).

Izenpe did make one related mistake when issuing this cert back in 
(presumably) 2010 though: the signature parameters in the TBSCertificate 
are omitted, whereas they should be an ASN.1 NULL (and so 
https://crt.sh/?id=1477430=cablint reports the error "RSA signatures 
must have a parameter specified").

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[info--- via dev-security-policy]

El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling  escribió:
> On 09/10/2018 23:53, Wayne Thayer wrote:
> > On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
> > Wayne, Kathleen:
> > Given the number of times that all the CAs in Mozilla's Root Program
> > have been reminded about Mozilla's requirements for disclosing
> > intermediate certs, I wouldn't blame you if you decided to add these 20
> > intermediate certs [5] to OneCRL immediately!
> > 
> > I think we should give this serious consideration, although it doesn't 
> > help with the majority of these that are trusted for email.
> 
> Hi Wayne.  Did you give this serious consideration?
> 
> An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for 
> well over a month, but hasn't yet been disclosed to the CCADB.
> 
> 
> [1] https://crt.sh/?id=966433897
> 
> [2] https://crt.sh/mozilla-disclosures
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited

We're reviewing what happened with this subCA, because it's reported to the 
CCADB (like all other subCAs). At the moment we've seen that there are two 
different entries in the crt.sh with the same serial number, but different 
fingerprints:

https://crt.sh/?id=1477430 -> disclosed
https://crt.sh/?id=966433897 -> not disclosed

This CA is not new, so there wouldn’t be any problem. But we continue analyzing 
what happened.

Thanks for the information.
Regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Yet more undisclosed intermediates

[Rob Stradling via dev-security-policy]

On 09/10/2018 23:53, Wayne Thayer wrote:
> On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:
> Wayne, Kathleen:
> Given the number of times that all the CAs in Mozilla's Root Program
> have been reminded about Mozilla's requirements for disclosing
> intermediate certs, I wouldn't blame you if you decided to add these 20
> intermediate certs [5] to OneCRL immediately!
> 
> I think we should give this serious consideration, although it doesn't 
> help with the majority of these that are trusted for email.

Hi Wayne.  Did you give this serious consideration?

An Izenpe intermediate cert [1] has been known to crt.sh (see [2]) for 
well over a month, but hasn't yet been disclosed to the CCADB.


[1] https://crt.sh/?id=966433897

[2] https://crt.sh/mozilla-disclosures

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Use cases of publicly-trusted certificates

[Jakob Bohm via dev-security-policy]

On 30/12/2018 14:18, Nick Lamb wrote:

On Thu, 27 Dec 2018 22:43:19 +0100
Jakob Bohm via dev-security-policy
 wrote:


You must be traveling in a rather limited bubble of PKIX experts, all
of whom live and breathe the reading of RFC5280.  Technical people
outside that bubble may have easily misread the relevant paragraph in
RFC5280 in various ways.


It's practically a pub quiz question. I appreciate that I might be
unusual in happening to care about this as a lay person, but for a
public CA in the Web PKI correctly understanding this stuff was _their
job_. It isn't OK for them to be bad at their jobs.


Pub quiz questions are particularly tailored to refer to arcane and
unexpected facts, which some punters have memorized.




The documents that prescribes the exact workings of DNS do not
prohibit (only discourage) DNS names containing underscores.  Web
browser interfaces for URL parsing may not allow them, which would be
a technical benefit for at least one usage of such certificates
reported in the recent discussion.


We get it, you don't accept that not all DNS names can be names of
hosts. That you still seem determined not to understand this even
when it's explained repeatedly shows that my characterization of this
position was correct.


I accept that not all DNS names can be names of hosts.  I do not accept
(without further proof) that certificate issuance is banned for DNS
labels that do not refer to hosts at all.  In this case because some
(unknown) higher level protocol requires the TLS server name to be a
label of a special form, specifically designed not to be a host name.

And I certainly do not expect subscribers to be aware of such arcane
details, subscribers know that certain proof of domain control is
required, and if they provide that proof and get a certificate
accordingly, they expect that to be perfectly valid and reliable
until otherwise informed by the issuing CA.




That I disagree with you on certain questions of fact doesn't mean
I'm unreliable, merely that you have not presented any persuasive
arguments that you are not the one being wrong.


I can't distinguish people who are "actually" unreliable from people
who claim the plain facts are "unpersuasive" to their point of view, and
so I don't. Likewise m.d.s.policy largely doesn't care whether a CA's
problems are a result of incompetence or malfeasance, same outcome
either way: distrust.



You keep ignoring that I am arguing the perspective of the subscribers,
not the CAs.


I merely
dispute that this was obvious to every reader of those documents


Since you like legal analogies, the usual standard in law is that
something was known _or should have been known_. This means that a
declaration that you didn't know something holds no weight if a court
concludes that you _should_ have known it. If you have a responsibility
to know, "I didn't know" is not usually an excuse.

I don't believe subscribers should have known, but I do believe
Certificate Authorities should have known, or, as corporate entities,
should have employed someone who knew that this was an important thing
to understand, did their research and came back with a "No" that had
the effect of setting issuance policy.



Which is precisely my point.  There are lots of people outside the tiny 
public CA technical and policy community who are technical experts but 
unaware of that highly obscure reading of RFC5280.



Doubtless some ordinary subscribers believe Africa is a country. I
don't have a problem with that. But I hope we agree that a CA should
not sign a certificate which gives C=AP (an ISO code reserved for other
reasons associated with Africa) on the rationale that they thought
Africa is a country.



Our disagreement would be if multiple such CAs had issued a bunch of
C=AP certificates to relevant organizations for use in some scheme that
has been technically locked to this aspect.  In such a case it would be
reasonable to allow those organizations to remove that technical lock,
then get new certificates in an orderly fashion.


A better example is the pre-2015 issuing of .onion names, which do
not exist in the IANA-rooted DNS.


A better example in the sense that, if this happened today we would
expect CAs not to issue for such a name without first getting a change
to the BRs saying this hierarchy is special ?

If the situation was that CAs had sensibly not issued for underscores,
then asked if they could and been turned down this entire thread would
not exist.



I strongly suspect (but have no data) that underscore certificates may
date back a long time as a practice, perhaps even before the CAB/F was
established.



I wrote this in opposition to someone seemingly insisting that the
_name_ implied that all non-web uses are mistakes that should not be
given any credence.


You wrote it in reply to me, and you quoted me. I don't know whether my
reciting these facts will be "persuasive" to you, but once again
refusing to believe something won't stop it being 

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

[Jakob Bohm via dev-security-policy]

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 
>  > 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 
> ".  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 
> ".  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/ ✪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