Re: O=U.S. Government for non-USG entity (IdenTrust)

[Eric Mill via dev-security-policy]

Thank you for the continued updates, and for relaying the deadline by which
these will be revoked.

On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> > On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg
> wrote:
> > > > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > > > >
> > > > > Hello, In reference to 3)"Certificates that appear to be intended
> as client certificates, but have the anyExtendedKeyUsage EKU, putting them
> in scope for the Mozilla Root Policy."
> > > > > The following 6 client certificates that have been identified as
> server certificates and have been flagged as non-compliant.  However, these
> certificates do not contain FQDN, IP Address, nor ‘TLS Web Server
> Authentication’ EKU.  As such in order for us to proceed with our analysis
> and determine if any remediation is required, we need clarification in the
> exact nature of non-compliance as it relates to Mozilla Root Policy or CAB
> Forum Baseline Requirement (ideally with pointer to the specific
> requirement in the corresponding documents).
> > > >
> > > > The Mozilla Root Store Policy section 1.1 (Scope) says:
> > > >
> > > > > This policy applies, as appropriate, to certificates matching any
> of the following (and the CAs which control or issue them):
> > > > > …
> > > > > 3. End-entity certificates which have at least one valid,
> unrevoked chain up to such a CA certificate through intermediate
> certificates which are all in scope, such end-entity certificates having
> either:
> > > > > - an Extended Key Usage (EKU) extension which contains one or more
> of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth,
> id-kp-emailProtection; or: …
> > > >
> > > > The six certificates linked contain the anyExtendedKeyUsage
> KeyPurposeId and were issued by an intermediate that is also in scope, so
> they are in scope for the Mozilla Root Policy and by extension the Baseline
> Requirements.
> > > >
> > > > Jonathan
> > >
> > > As an update to the reported issue of misclassification of client
> certificates as server certificates, based on our continuing internal
> investigations, feedback from our user community, and also taking into
> account the feedback posted in this forum, we plan to proceed as follows:
> > > 1.Nolater than August 31, 2017 we will discontinue new or reissuance
> of human certificate with the anyExtendedKeyUsage extension from all
> IdenTrust ACES CAs.
> > > 2.We will allow continued use of the current certificates and replace
> or let them expire through natural lifecycle because:
> > > a. These certificates are not sever certificates
> > > b. All certificates issued are from audited CA(s) with public
> disclosure of audit result
> > > c. The legacy application usage requires anyExtendedKeyUsage extension
> at the present time though we are phasing out support of such application.
> > > d. These certificates do not pose a security concern meriting
> immediate revocation
> > > e.  Replacement of these certificates will result in significant
> negative impact on our customers.
> >
> > Effective August 28, 2017, IdenTrust has discontinued new issuance or
> reissuance of human certificates with the anyExtendedKeyUsage extension
> from all IdenTrust ACES CAs.
>
>
> IdenTrust continues to work our customers in revoking/replacing ACES SSL
> certificates with these reported issues:
> - https for OCSP validation instead of http in AIA extension;
> - Invalid “US Government” as o= in the SDN;
> - Invalid OtherName in the SAN extension.
> For those customers that have not replaced their certificates by September
> 15, 2017, we will revoke their them.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: O=U.S. Government for non-USG entity (IdenTrust)

[identrust--- via dev-security-policy]

On Monday, August 28, 2017 at 3:28:01 PM UTC-4, iden...@gmail.com wrote:
> On Friday, August 18, 2017 at 7:22:06 PM UTC-4, iden...@gmail.com wrote:
> > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote:
> > > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy 
> > > >  wrote:
> > > > 
> > > > Hello, In reference to 3)"Certificates that appear to be intended as 
> > > > client certificates, but have the anyExtendedKeyUsage EKU, putting them 
> > > > in scope for the Mozilla Root Policy."
> > > > The following 6 client certificates that have been identified as server 
> > > > certificates and have been flagged as non-compliant.  However, these 
> > > > certificates do not contain FQDN, IP Address, nor ‘TLS Web Server 
> > > > Authentication’ EKU.  As such in order for us to proceed with our 
> > > > analysis and determine if any remediation is required, we need 
> > > > clarification in the exact nature of non-compliance as it relates to 
> > > > Mozilla Root Policy or CAB Forum Baseline Requirement (ideally with 
> > > > pointer to the specific requirement in the corresponding documents).
> > > 
> > > The Mozilla Root Store Policy section 1.1 (Scope) says:
> > > 
> > > > This policy applies, as appropriate, to certificates matching any of 
> > > > the following (and the CAs which control or issue them):
> > > > …
> > > > 3. End-entity certificates which have at least one valid, unrevoked 
> > > > chain up to such a CA certificate through intermediate certificates 
> > > > which are all in scope, such end-entity certificates having either:
> > > > - an Extended Key Usage (EKU) extension which contains one or more of 
> > > > these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, 
> > > > id-kp-emailProtection; or: …
> > > 
> > > The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId 
> > > and were issued by an intermediate that is also in scope, so they are in 
> > > scope for the Mozilla Root Policy and by extension the Baseline 
> > > Requirements.
> > > 
> > > Jonathan
> > 
> > As an update to the reported issue of misclassification of client 
> > certificates as server certificates, based on our continuing internal 
> > investigations, feedback from our user community, and also taking into 
> > account the feedback posted in this forum, we plan to proceed as follows:
> > 1.Nolater than August 31, 2017 we will discontinue new or reissuance of 
> > human certificate with the anyExtendedKeyUsage extension from all IdenTrust 
> > ACES CAs. 
> > 2.We will allow continued use of the current certificates and replace or 
> > let them expire through natural lifecycle because: 
> > a. These certificates are not sever certificates
> > b. All certificates issued are from audited CA(s) with public disclosure of 
> > audit result
> > c. The legacy application usage requires anyExtendedKeyUsage extension at 
> > the present time though we are phasing out support of such application.
> > d. These certificates do not pose a security concern meriting immediate 
> > revocation
> > e.  Replacement of these certificates will result in significant negative 
> > impact on our customers.
> 
> Effective August 28, 2017, IdenTrust has discontinued new issuance or 
> reissuance of human certificates with the anyExtendedKeyUsage extension from 
> all IdenTrust ACES CAs.


IdenTrust continues to work our customers in revoking/replacing ACES SSL 
certificates with these reported issues: 
- https for OCSP validation instead of http in AIA extension;
- Invalid “US Government” as o= in the SDN;
- Invalid OtherName in the SAN extension.
For those customers that have not replaced their certificates by September 15, 
2017, we will revoke their them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Idea for a stricter name constraint interpretation

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 31/08/2017 22:26, Ryan Sleevi wrote:
>
>> Agreed. But in general, in order to maintain interoperability, there's a
>> process for building consensus, and repurposing extensions as you propose
>> is generally detrimental to that :)
>>
>
> But sometimes necessary.
>

There is a tremendous burden of proof to demonstrate this, and it's the
path of last resort, not first.


> Moving the information to a new extension would basically just bloat
>>> certificates with more redundant data to be sent in every certificate
>>> based protocol exchange.  But changing the original decision in a
>>> backwards compatible manner may still be a good idea, either as a
>>> "stricter security policy" or (better, if it works well in controlled
>>> tests) as part of an update RFC for the IETF standard that specified the
>>> original semantics.
>>>
>>
>>
>> I can understand your perspective, but I must disagree with you that it's
>> "backwards compatible". It isn't - it's a meaningful semantic change that
>> breaks interoperability.
>>
>>
> I meant backwards compatible and interoperable with the actual real
> world CAs (as opposed to all the CAs that could be built under the old
> standard).  Compare to how the standard was changed from DNS name in the
> CN element to DNS name exclusively in the SAN extension, but hopefully
> with less transition time needed.


I believe this may be operating on an incomplete knowledge of history. RFC
2818 (aka the HTTPS RFC) always indicated commonName was deprecated (and
SAN was preferred), and nameConstraints have similarly always expressed a
path for constraining the nameConstraints.

So, from the get-go with the standards, it was possible to name constrain
DNS. Unless you were referencing certificates prior to them being bound to
domain names, but I can't see how that would be relevant, since the context
is about DNS names.


> Yes, it means that technically constrained sub-CA certificates may be
>> 'bloated' in order to ensure the desired degree of security. That's a
>> trade-off for the compromises necessary to avoid audits. That's not,
>> however, an intrinsic argument against the process, or a suggestion it
>> cannot be deployed.
>>
>>
> Avoiding audit failures is a legal, not a technical need.  Anything that
> would only fail audits could be fixed by changing audit requirements, if
> the organizations setting those (such a Mozilla and CAB/F) desires.
>

I didn't suggest avoiding audit failures, but rather, avoiding audits. That
is, the material difference between a TCSC and a CA is not one of technical
requirements (they're the same, effectively), but one of whether or not a
self-audit is seen as acceptable versus an independent third-party audit.

I highlight this because it makes the tradeoff something more concrete: An
organization that wishes to avoid the administrative hassle of an
independent audit could opt for a technically constrained sub-CA, which
would be "bloated" in your view. If they didn't want the bloat, they could
accept the administrative hassle of an independent third-party audit.

That is, there are options to satisfy an organizations needs, and allows
them to prioritize whether it's more important to have the size reduction
or to have organizational flexibility. There's no innate requirement to
allow both - and while that may be an optimization, is one that comes with
the compatibility and interoperability risks I highlighted, so it may not
actually be achievable in the world we have. But that's OK - organizations
and individuals routinely have to operate in the world we have and make
choices based on priorities, and we've made it so far :)


>
>
>> The interaction between a nameConstraints extension not specifying
>>> directorynames and the directoryname in the Subject field would be an
>>> area
>>> needing careful specification, based on compatibility and historic
>>> concerns.
>>>
>>>
>> Yes. Which would not be appropriate for m.d.s.p (for reasons of both
>> consensus and intellectual property). That is a concern for some members,
>> and is why organizations like W3C and groups such as WICG exist :)
>>
>>
> Ok, I was simply hoping informal discussion in a place like m.d.s.p.
> would be a better place to initial evaluate such an idea before starting
> up the whole standardization process.
>

Fair enough. This makes a great venue for that, but certainly, as it shifts
to technical details, working through a process like WICG - in which you
could write up an 'explainer' explaining the idea and how you think it
should work, sans technical details, to gauge interest while providing some
of the protections, and then iterate and incubate should there be interest
- is a great way to accelerate that.

Please don't take this as a lack of interest or a suggestion the work isn't
valuable - I think it is interesting, and the work is valuable - but it is
one 

Re: Idea for a stricter name constraint interpretation

[Jakob Bohm via dev-security-policy]

On 31/08/2017 22:26, Ryan Sleevi wrote:

On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I am aware that this was the original specification.  However like many
other parts of PKIX it may not be as good in 20/20 hindsight.



Agreed. But in general, in order to maintain interoperability, there's a
process for building consensus, and repurposing extensions as you propose
is generally detrimental to that :)



But sometimes necessary.




Moving the information to a new extension would basically just bloat
certificates with more redundant data to be sent in every certificate
based protocol exchange.  But changing the original decision in a
backwards compatible manner may still be a good idea, either as a
"stricter security policy" or (better, if it works well in controlled
tests) as part of an update RFC for the IETF standard that specified the
original semantics.



I can understand your perspective, but I must disagree with you that it's
"backwards compatible". It isn't - it's a meaningful semantic change that
breaks interoperability.



I meant backwards compatible and interoperable with the actual real
world CAs (as opposed to all the CAs that could be built under the old
standard).  Compare to how the standard was changed from DNS name in the
CN element to DNS name exclusively in the SAN extension, but hopefully
with less transition time needed.


At the least, that's something that bears documentation and consensus -
that is, don't "embrace, extend, extinguish" - if you will.



Of cause.


Yes, it means that technically constrained sub-CA certificates may be
'bloated' in order to ensure the desired degree of security. That's a
trade-off for the compromises necessary to avoid audits. That's not,
however, an intrinsic argument against the process, or a suggestion it
cannot be deployed.



Avoiding audit failures is a legal, not a technical need.  Anything that
would only fail audits could be fixed by changing audit requirements, if
the organizations setting those (such a Mozilla and CAB/F) desires.




The interaction between a nameConstraints extension not specifying
directorynames and the directoryname in the Subject field would be an area
needing careful specification, based on compatibility and historic concerns.



Yes. Which would not be appropriate for m.d.s.p (for reasons of both
consensus and intellectual property). That is a concern for some members,
and is why organizations like W3C and groups such as WICG exist :)



Ok, I was simply hoping informal discussion in a place like m.d.s.p.
would be a better place to initial evaluate such an idea before starting
up the whole standardization process.




A first order approximation would be that the absence of directory name
constraints in a non-empty nameconstraints extension would not prohibit the
(mandatory) inclusion of a directory name as the Subject Name of a
certificate (but would still block its inclusion as a SAN).



It does, as proposed, so your proposal is not 'backwards compatible'
anymore :)



Well since its only a property of an interpretation of my own first
draft wording, this is simply a fix of the proposal long before
implementation.




A second order approximation could apply certain non-directory-name
constraint semantics to certain directory name elements.  For example
an "emailAddress" directory name field could be subject to the
constraints for rfc822name absent explicitly contradictory directory
name constraints.  An official specification would have to enumerate
these situations explicitly.



Indeed.



However in practice, such a replacement of (relying part redistributed)
SubCA certificates would be at least as difficult as simply switching to
a new SubCA.  Either solution would be unlikely to make subscribers stop
distributing the old SubCA cert with their existing non-expired end
cert, but changing to a new SubCA would at least prevent accidental
reuse of the expired/revoked SubCA cert with new end certs.



They are not relying party distributed. They're subscriber distributed. And
as the Subscriber has a direct or transitive relationship with the Issuer,
that's not unreasonable.


Sorry, typo.



I agree that it's an error prone process, and I agree that changing the
name (and not just the key) is an ideal scenario to transition. However,
unless you revoke the old certificate, it's unconstrained. And if you
revoke the old certificate, then everything it's issued is no longer valid,
unless you reissue for the same name and key with new constraints. Which is
why folks thought it was a good idea at the time.



Alternatively, one could choose a definition of "unconstrained" which
doesn't require impracticable revocations of real world certificates
that were considered fully constrained under previous definitions.

This is the motivation for my proposal that browsers etc. wanting to
require additional "all ban" naming constraints might instead 

Re: Idea for a stricter name constraint interpretation

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I am aware that this was the original specification.  However like many
> other parts of PKIX it may not be as good in 20/20 hindsight.


Agreed. But in general, in order to maintain interoperability, there's a
process for building consensus, and repurposing extensions as you propose
is generally detrimental to that :)


> Moving the information to a new extension would basically just bloat
> certificates with more redundant data to be sent in every certificate
> based protocol exchange.  But changing the original decision in a
> backwards compatible manner may still be a good idea, either as a
> "stricter security policy" or (better, if it works well in controlled
> tests) as part of an update RFC for the IETF standard that specified the
> original semantics.


I can understand your perspective, but I must disagree with you that it's
"backwards compatible". It isn't - it's a meaningful semantic change that
breaks interoperability.

At the least, that's something that bears documentation and consensus -
that is, don't "embrace, extend, extinguish" - if you will.

Yes, it means that technically constrained sub-CA certificates may be
'bloated' in order to ensure the desired degree of security. That's a
trade-off for the compromises necessary to avoid audits. That's not,
however, an intrinsic argument against the process, or a suggestion it
cannot be deployed.


> The interaction between a nameConstraints extension not specifying
> directorynames and the directoryname in the Subject field would be an area
> needing careful specification, based on compatibility and historic concerns.
>

Yes. Which would not be appropriate for m.d.s.p (for reasons of both
consensus and intellectual property). That is a concern for some members,
and is why organizations like W3C and groups such as WICG exist :)


> A first order approximation would be that the absence of directory name
> constraints in a non-empty nameconstraints extension would not prohibit the
> (mandatory) inclusion of a directory name as the Subject Name of a
> certificate (but would still block its inclusion as a SAN).
>

It does, as proposed, so your proposal is not 'backwards compatible'
anymore :)


> A second order approximation could apply certain non-directory-name
> constraint semantics to certain directory name elements.  For example
> an "emailAddress" directory name field could be subject to the
> constraints for rfc822name absent explicitly contradictory directory
> name constraints.  An official specification would have to enumerate
> these situations explicitly.


Indeed.


> However in practice, such a replacement of (relying part redistributed)
> SubCA certificates would be at least as difficult as simply switching to
> a new SubCA.  Either solution would be unlikely to make subscribers stop
> distributing the old SubCA cert with their existing non-expired end
> cert, but changing to a new SubCA would at least prevent accidental
> reuse of the expired/revoked SubCA cert with new end certs.


They are not relying party distributed. They're subscriber distributed. And
as the Subscriber has a direct or transitive relationship with the Issuer,
that's not unreasonable.

I agree that it's an error prone process, and I agree that changing the
name (and not just the key) is an ideal scenario to transition. However,
unless you revoke the old certificate, it's unconstrained. And if you
revoke the old certificate, then everything it's issued is no longer valid,
unless you reissue for the same name and key with new constraints. Which is
why folks thought it was a good idea at the time.

I'm not trying to defend the ideas as good - the idea of making
nameConstraints a whitelist, rather than a blacklist, has been something
bandied about for the better part of a decade. However, it's a mistake we
have to live with, and if we want to correct it, it means specifying
something new, and in a way that is interoperable, both with the old and
others. I tried to give you a suggestion on how to do so, should you feel
motivated to pursue it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Idea for a stricter name constraint interpretation

[Jakob Bohm via dev-security-policy]

On 31/08/2017 21:49, Ryan Sleevi wrote:

On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Would it be beneficial to Mozilla in particular and the larger PKI
community in general if the following was added to implementations:



Hi Jakob,

This was rather extensively discussed in the IETF during the production of
the nameConstraints extension - whether to fail open or fail closed, if you
will, with unrecognzied name types.



I am aware that this was the original specification.  However like many
other parts of PKIX it may not be as good in 20/20 hindsight.


The existing RFCs document the behaviour that is implemented by clients, so
no, it would not be wise to repurpose this behaviour in a contradictory way
- that would go against the mission of ensuring an interoperable Web based
on shared standards.

The approach to change the semantic meaning of extensions in such a way is
to define a new such extension - which may have the same encoding, but have
the semantic processing restrictions you mentioned. One way that could be
done in an interoperable way is to ensure both the 'legacy' nameConstraints
extension (to handle the existing Web PKI) and the 'new'
nameConstraintsVersion2 extension (poorly named, but with the same ASN.1
production and different semantic meaning for processing) be required for a
certificate to be considered 'constrained'.



Moving the information to a new extension would basically just bloat
certificates with more redundant data to be sent in every certificate
based protocol exchange.  But changing the original decision in a
backwards compatible manner may still be a good idea, either as a
"stricter security policy" or (better, if it works well in controlled
tests) as part of an update RFC for the IETF standard that specified the
original semantics.



Such a document would ideally go through the IETF, but COULD be incubated
in an appropriate venue (such as WICG) to allow iterative and flexible
development.


That would indeed be the point.



However, the implementation isn't quite as 'simple' as you describe, and so
would require more work. For example, one flaw would be that unless such a
constrained certificate specified a Directory Name constraint, then every
certificate issued would be a violation of the name constraint unless it
was a fully empty subject ( see https://no-subject.badssl.com/ to
understand the compatibility issues this causes; particularly, try it on
macOS). So more work is needed.


The interaction between a nameConstraints extension not specifying 
directorynames and the directoryname in the Subject field would be an 
area needing careful specification, based on compatibility and historic 
concerns.


A first order approximation would be that the absence of directory name 
constraints in a non-empty nameconstraints extension would not prohibit 
the (mandatory) inclusion of a directory name as the Subject Name of a 
certificate (but would still block its inclusion as a SAN).


A second order approximation could apply certain non-directory-name
constraint semantics to certain directory name elements.  For example
an "emailAddress" directory name field could be subject to the
constraints for rfc822name absent explicitly contradictory directory
name constraints.  An official specification would have to enumerate
these situations explicitly.




But that general concern - of being able to extend new name types and not
necessarily have the CA be able to issue for them - has been discussed in
the past. The original idea was that as new name types are introduced that
have semantic meaning for applications, you would revoke the existing cert
and reissue a new one (with new constraints) using the same Subject/Key, as
that would ensure a continuity of validity for situations where you did
want to restrict the naming scheme. So, technically, there are options for
CAs today :)



However in practice, such a replacement of (relying part redistributed)
SubCA certificates would be at least as difficult as simply switching to
a new SubCA.  Either solution would be unlikely to make subscribers stop
distributing the old SubCA cert with their existing non-expired end
cert, but changing to a new SubCA would at least prevent accidental
reuse of the expired/revoked SubCA cert with new end certs.


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

Re: Idea for a stricter name constraint interpretation

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Would it be beneficial to Mozilla in particular and the larger PKI
> community in general if the following was added to implementations:
>

Hi Jakob,

This was rather extensively discussed in the IETF during the production of
the nameConstraints extension - whether to fail open or fail closed, if you
will, with unrecognzied name types.

The existing RFCs document the behaviour that is implemented by clients, so
no, it would not be wise to repurpose this behaviour in a contradictory way
- that would go against the mission of ensuring an interoperable Web based
on shared standards.

The approach to change the semantic meaning of extensions in such a way is
to define a new such extension - which may have the same encoding, but have
the semantic processing restrictions you mentioned. One way that could be
done in an interoperable way is to ensure both the 'legacy' nameConstraints
extension (to handle the existing Web PKI) and the 'new'
nameConstraintsVersion2 extension (poorly named, but with the same ASN.1
production and different semantic meaning for processing) be required for a
certificate to be considered 'constrained'.

Such a document would ideally go through the IETF, but COULD be incubated
in an appropriate venue (such as WICG) to allow iterative and flexible
development.

However, the implementation isn't quite as 'simple' as you describe, and so
would require more work. For example, one flaw would be that unless such a
constrained certificate specified a Directory Name constraint, then every
certificate issued would be a violation of the name constraint unless it
was a fully empty subject ( see https://no-subject.badssl.com/ to
understand the compatibility issues this causes; particularly, try it on
macOS). So more work is needed.

But that general concern - of being able to extend new name types and not
necessarily have the CA be able to issue for them - has been discussed in
the past. The original idea was that as new name types are introduced that
have semantic meaning for applications, you would revoke the existing cert
and reissue a new one (with new constraints) using the same Subject/Key, as
that would ensure a continuity of validity for situations where you did
want to restrict the naming scheme. So, technically, there are options for
CAs today :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[Nick Lamb via dev-security-policy]

Kurt, I think both the past experiences of m.d.s.policy with incidents that 
went undetected by auditors, and my own personal experience (not as part of the 
Web PKI) with professional audit firms is that they're not strong on the sort 
of technical requirements that we've seen here.

If the rule says I ought to have annual meeting at which I must keep minutes, 
the auditors are likely to remember to ask to see the minutes and to identify 
"did not hold required meetings" as a problem. If the rule says I mustn't issue 
certs with a "foo" extension it's very unlikely the auditors will inspect any 
certs - let alone all of them - specifically to check for that extension. This 
is definitely a limitation that we need to keep in mind and which CAs 
themselves must keep in mind if relying on audits in their own business - as 
for example Symantec did.

As a rule of thumb, audit is good at identifying certain types of policy 
problems but not effective for detecting criminality or bugs. If you want to 
detect those (and we do) you need other measures in place.

That said, I would like to see feedback from CAs on why *they* missed this and 
what they've done to try not to be on the list next time something like this 
happens. They too need to be aware that passing audit is the low bar, if it's 
the extent of their goals then Mozilla's root programme probably isn't for them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violations of Baseline Requirements 4.9.10

[David Fernandez via dev-security-policy]

El miércoles, 30 de agosto de 2017, 10:58:34 (UTC+2), Paul Kehrer  escribió:
> Hi David,
> 
> If you use the cert at https://crt.sh/?id=1616324 as issuer (the root
> itself) and run this command:
> 
> openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101
> -url http://ocsp.izenpe.com -noverify
> 
> You will get back
> 
> This Update: Jun 22 11:06:43 2017 GMT
> Next Update: Jun 22 11:06:43 2018 GMT
> 
> Of course, no serverAuth certificates should be issued directly off the
> root, but the root is still enabled for that purpose so the responder
> should respond UNAUTHORIZED here (UNAUTHORIZED instead of UNKNOWN to allow
> the root to stay offline).
> 
> On August 30, 2017 at 4:42:10 PM, David Fernandez via dev-security-policy (
> dev-security-policy@lists.mozilla.org) wrote:
> 
> Hi Paul,
> can you provide what you posted, for example attaching the ocsp response. I
> mean if I query for a non-existant certificate, I get the following answer:
> 
> openssl ocsp -no_cert_verify -no_signature_verify -issuer SSLEV_IZENPE.cer
> -serial 0x295990755083049101712519384020072382191 -url
> http://ocsp.izenpe.com
> 
> Response verify OK
> 0x295990755083049101712519384020072382191: revoked
> This Update: Aug 30 08:36:05 2017 GMT
> Next Update: Sep 1 08:36:05 2017 GMT
> Reason: certificateHold
> Revocation Time: Jan 1 00:00:00 1970 GMT
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


Hi Paul,
We have been looking for the same problem in all our IZENPE's Subordinate CAs, 
and found that the problem was only affecting to our Root.
After performing the changes to fix the problem and validations in our 
Development system, we have fix the problem in our production enviroment a 
couple of hours ago.
Thank you for warning all of us.

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

Idea for a stricter name constraint interpretation

[Jakob Bohm via dev-security-policy]

Over the past many months, a few situations have arisen where SubCAs
intended to be constrained were not constrained according to the rules,
because they lacked "exclude all" name constraints for name types they
were not supposed to issue at all.

Would it be beneficial to Mozilla in particular and the larger PKI
community in general if the following was added to implementations:

  If an issuing CA cert specifies at least one name constraint, name
  types with no explicit name constraint (such as an allow-all
  constraint), are reinterpreted as "deny all" instead of "allow all" ?

Note that CA certs with no name constraints at all remain unconstrained
as intended.

Obviously, such a change would need to be checked against the corpus of
known public CAs, including past CAs that may still be trusted for
things like e-mail signatures on old e-mails still in peoples mail
boxes.



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

Re: Violations of Baseline Requirements 4.9.10

[Kurt Roeckx via dev-security-policy]

On 2017-08-29 14:47, Paul Kehrer wrote:

I've recently completed a scan of OCSP responders with a focus on checking
whether they are compliant with BR section 4.9.10's requirement: "Effective
1 August 2013, OCSP responders for CAs which are not Technically
Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD"
status for such certificates."


I have to wonder why you were able to find so many. Is this not covered 
in the audit?



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

Re: Violations of Baseline Requirements 4.9.10

[Jakob Bohm via dev-security-policy]

On 31/08/2017 07:24, Peter Miškovič wrote:

Hi Paul,
we found the problem with OCSP response for SubCA R1I1 and SubCA R2I2 and fixed 
it yesterday afternoon.
Problem with OCSP response for RootCA will be fixed to the end of next week. 
They are offline and there is no real possibility to issue a SSL certificate 
directly by them even if  they are enabled for issuing.



Please be aware that the requirement is there to avoid positive
responses for fake certificates that were never issued by the real CA
(such as in the DigiNotar incident).

But I understand the need to use slower, more careful update procedures
for root CA related infrastructure.  (I don't speak for Mozilla).


Regards
Peter Miskovic


From: Paul Kehrer [mailto:paul.l.keh...@gmail.com]
Sent: Tuesday, August 29, 2017 2:48 PM
To: 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Violations of Baseline Requirements 4.9.10

I've recently completed a scan of OCSP responders with a focus on checking whether they are 
compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for 
CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a 
"GOOD" status for such certificates." This rule was put in place in the wake of the 
DigiNotar incident as an additional method of ensuring the CA is aware of all issuances in its 
infrastructure and has been a requirement for over 4 years now.

The scan was performed by taking the list of responders (and valid issuer name 
hash/issuer key hashes) that Andrew Ayer has aggregated and making an OCSP request for 
the serial number "0xdeadbeefdeadbeefdeadbeefdeadbeef". This serial is 
extremely unlikely to have been issued legitimately.

The following OCSP responders appear to be non-compliant with the BRs (they 
respond GOOD and are not listed as technically constrained by crt.sh) but are 
embedded in certificates issued in paths that chain up to trusted roots in the 
Mozilla store. I have grouped them by owner where possible and put notes about 
whether they've been contacted:


CA Disig a.s.

Email sent to tspnot...@disig.sk

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service
Example cert: 
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service
Example cert: 
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
Example cert: 
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
Example cert: 
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2


-Paul




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

Re: Violations of Baseline Requirements 4.9.10

[Paul Kehrer via dev-security-policy]

I have updated the list below to try to capture all the information
provided in this thread about which responders have been fixed (and
verified using another random serial number), which ones have a date, and
removed the ones that are actually under technical constraint that I missed.

I have received several responses from CAs that were CC'd informing me that
they are investigating but until the issues are resolved or I have a date
for resolution I have not noted those communications below.


AS Sertifitseerimiskeskuse (SK)

CCADB does not list an email address. Not CC'd.

DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
emailAddress=p...@sk.ee
Example cert:
https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
OCSP URI: http://ocsp.sk.ee/CA

Autoridad de Certificacion Firmaprofesional

Email sent to i...@firmaprofesional.com

DN: C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
Example cert:
https://crt.sh/?q=cd74198d4c23e4701dea579892321b9e4f47a08bd8374710b899aad1495a4b35
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, emailAddress=c...@firmaprofesional.com, L=C/ Muntaner 244
Barcelona, OU=Consulte http://www.firmaprofesional.com, OU=Jerarquia de
Certificacion Firmaprofesional, O=Firmaprofesional S.A. NIF A-62634068,
CN=AC Firmaprofesional - CA1
Example cert:
https://crt.sh/?q=649d5190f9fff58de60313c2f0598393f9dba05368b1dbfe93ec806015fb8796
OCSP URI: http://ocsp.firmaprofesional.com

DN: C=ES, O=Firmaprofesional SA, OU=Certificados Digitales para la
Administracion Publica, serialNumber=A62634068, CN=AC Firmaprofesional -
AAPP
Example cert:
https://crt.sh/?q=d4ef928ee32c3838d40e5756b523829b1dafcd46fd84428ba03d59330a4ae5e7
OCSP URI: http://ocsp.firmaprofesional.com

CA Disig a.s.

Email sent to tspnot...@disig.sk

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R1I1 Certification Service
Example cert:
https://crt.sh/?q=da74b18f3651bf90a8b2c07f8df294de19e441dcaa6913627261752199c302a2
OCSP URI: http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig R2I2 Certification Service
Example cert:
https://crt.sh/?q=1a088e912ddb15a3b52ab1396af2a1ce0dcfab170e007e551f63231c76975417
OCSP URI: http://subcar2i2-ocsp.disig.sk/ocsp/subcar2i2

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R1
Example cert:
https://crt.sh/?q=e1abb0faeaa7312f2c3e041cbd2df03a507e346b9716442463ed61106aff6947
OCSP URI: http://rootcar1-ocsp.disig.sk/ocsp/rootcar1

DN: C=SK, L=Bratislava, O=Disig a.s., CN=CA Disig Root R2
Example cert:
https://crt.sh/?q=239ffa86d71033ba255914782057d87e8421aedd5910b786928b6a1248c3e341
OCSP URI: http://rootcar2-ocsp.disig.sk/ocsp/rootcar2

certSIGN

Email sent to off...@certsign.ro

DN: C=RO, O=certSIGN, OU=certSIGN Enterprise CA Class 3 G2, CN=certSIGN
Enterprise CA Class 3 G2
Example cert:
https://crt.sh/?q=98ab1983ae9f6a6116e5010e3ab2b1b0bf266fa205a140b1bc1d340ff4ff6355
OCSP URI: http://ocsp.certsign.ro
Notes: This is fixed as of 2017-08-31

DN: C=RO, O=certSIGN, OU=certSIGN ROOT CA
Example cert:
https://crt.sh/?q=3003bf8853427c7b91023f7539853d987c58dc4e11bbe047d2a9305c01a6152c
OCSP URI: http://ocsp.certsign.ro
Notes: Per Cristian Garabet this will be resolved 2017-09-15

Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)

CCADB does not list an email address. Not CC'd.

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=88f6298c5a8cc66cefb8ea214a528c3efce36a26213fe4fd260613967d39e7d4
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2  (c)03, OU=Administracions
Locals de Catalunya, CN=EC-AL
Example cert:
https://crt.sh/?q=1869a83f83b8f034336ab09fe52563c00c80c4b45897b3ea15e658fd14306208
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2   (c)03, OU=Secretaria
d'Administracio i Funcio Publica, CN=EC-SAFP
Example cert:
https://crt.sh/?q=15d3c7463f477e2627c4c9a158e429abd6bfe63101d6745560a36d1c03363d30
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11 08008 Barcelona, OU=Serveis Publics de Certificacio
ECV-2, OU=Vegeu https://www.catcert.net/verCIC-2 (c)03, OU=Universitats i
Recerca, CN=EC-UR
Example cert:
https://crt.sh/?q=7432b4c29e1360668814ec282ad78208cd521e62b8d8d60d5084fdf8daad57cb
OCSP URI: http://ocsp.catcert.net

DN: C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), L=Passatge
de la Concepcio 11