On 05/12/2018 20:45, Wayne Thayer wrote:
.On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy <
[email protected]> wrote:
...
>
Further actions made:
Microsec modified the CISCO VPN server policy to issue the
certificates only for two years in the future.
Microsec decided to discuss the situation of the CISCO VPN server
certificates and make the necessary modifications (if needed) to fully
comply with the BR requirements in case of CISCO VPN server certificates
too.
The reason of the problem is that Microsec couldn’t find clear instruction
or specifications about the requirements regarding the CISCO VPN server
certificates.
They are very similar to the TLS certificates, but they have slightly
different usage and different extended key usage values.
Because these certificate can be used for TLS, as far as Mozilla is
concerned, they **are** TLS certificates, and all Mozilla policies for TLS
certificates apply.
The main difference is that the CISCO VPN server certificates contain the
following EKU values which should not be present in the TLS certificates:
ipsecEndSystem (1.3.6.1.5.5.7.3.5),
ipsecIntermediateSystem (1.3.6.1.5.5.8.2.2)
The easiest way would be to manage the CISCO VPN server certificates as a
TLS certificate.
Do you perform linting on certificates issued under the TLS profile?
Our questions are:
is it allowed to issue CISCO VPN server certificates with the same
CA which issues TLS certificates?
Only if those certificates fully comply with Mozilla policy for TLS
certificates.
will not cause the extra EKU values any problems for the CABF in
the (near) future?
This problem is best answered by the CAB Forum ([email protected]),
but in my opinion the Baseline Requirements permit the issuance of
certificates containing "extra" EKU values as long as they comply with
section 7.1.4.2, including:
-------------
Extensions that do not apply in the context of the public Internet (such as
an extendedKeyUsage value for a service that is only valid in the context
of a privately managed network), unless:
such value falls within an OID arc for which the Applicant demonstrates
ownership, or
the Applicant can otherwise demonstrate the right to assert the data in a
public context
These appear to be IETF OIDs for IETF standard IPSEC, applicable to the
public Internet even if the specific CISCO servers only accept login
from specific users.
--------------
It is not clear to me that Cisco VPN server certificates meet the
requirements that 'extensions apply in the context of the public Internet'.
is it possible to send the CISCO VPN server pre-certificates to the
CT log servers and include the answers in the certificate?
This question is best answered by Cisco, but I think this should be
possible,
is it still really necessary to include these extra EKU values in
the CISCO VPN server certificates, or can CISCO devices work with fully TLS
compatible certificates?
This is also a question for Cisco. Someone on this list may be able to
provide an unofficial answer.
Another question of relevance:
Does the applicable VPN hardware and software (Cisco VPN servers and
compatible VPN clients) work with certificates that omit all the TLS-
related EKUs, thus allowing future VPN certificates to fall outside the
BRs ?
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
