Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Trustis Root Inclusion Request
519 views
Skip to first unread message
Kathleen Wilson
Jan 10, 2012, 5:19:57 PM1/10/12
to mozilla-dev-s...@lists.mozilla.org
Trustis has applied to add the “Trustis FPS Root CA” root certificate,
and turn on the websites and email trust bits.
Trustis is a commercial CA operating primarily in the UK and Europe.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=577665
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Trustis
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=587468
Noteworthy points:
* The primary documents are the CP and Minimum Enrolment Requirements.
The documents are in English.
Document Repository: http://www.trustis.com/pki/fpsia/
Minimum Enrolment Requirements:
http://www.trustis.com/pki/fpsia/policy/T-0104-002-ATL-013-Trustis-FPS-Minimum-Enrolment-Requirements-V3_0.pdf
Certificate Policy:
http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
Issuing Authority PKI Disclosure Statement:
http://www.trustis.com/pki/fpsia/policy/disclosure.htm
Subscriber Agreement:
http://www.trustis.com/pki/fpsia/policy/subscriber-agreement.htm
* CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=268357
* This root signs internally-operated Issuing CAs that sign end-entity
certs.
** The Trustis FPS Enterprise Authority is the subCA used for issuing
general SSL certificates.
** The Trustis DTP Issuing Authority does not issue SSL certificates.
** The Trustis Healthcare Issuing Authority issues SSL certificates to
UK NHS facilities.
* All subCAs issuing certificates must do so in accordance with the UK
Government Authentication Framework - Level 2. This is required for all
certificates from all of the FPS subCAs be they individual or SSL. In
the case of SSL, this means certs issued are of level 3 or higher.
Domains are validated but a number of other criteria relating to the
organization and the individual representing the organization must also
be satisfied.
UK Government Authentication Framework (GAF) – HMG Minimum Requirements
for Verification:
** Individuals:
http://www.cabinetoffice.gov.uk/media/252559/regindividualsv2.pdf
** Organizations:
http://www.cabinetoffice.gov.uk/media/252565/registra_orgs_v2.pdf
* The request is to turn on the Websites and Email trust bits.
* The following quotes are from the Minimum Enrolment Requirements
document:
** “Trustis FPS issues certificates to a number of levels of assurance
and authentication. In all cases certificates issued shall fulfil the
Standards of HMG Assurance Framework, specifically:
- HMG Minimum Requirements for the Verification of the Identity of
Individuals V2
- HMG Minimum Requirements for the Verification of the Identity of
Organisations V2 at level two.”
** “Note that a formal documented existing relationship with the RA may
be used in lieu of / with other evidence if the RA already has strong
confidence in the identity of the registrant organisation. Underlying
identification checks must have been previously performed and it is
essential to ensure that information used is up-to-date.”
** For Organization Representative, Type of Evidence Required:
“General person acceptable evidence Plus:
- organisational acceptable evidence
- evidence of affiliation to the organisation
- evidence of authority to act on behalf of the organisation
- verification of the representative through "back contact" with the
organization”
** “The registration data for the domain is collected from approved
and/or third party public sources (WHOIS) and corroborated against the
information verified as part of the individual or organisation
registration submitted in the application.
… Where third party or public evidence does not provide corroboration of
ownership of a domain, or an organisation or individual controls a
domain not registered with it. Certified written evidence of
ownership/control must be provided. This is verified and/or corroborated
with the registered owner of the domain.”
** “Certificates are not issued on the basis of email address only.
Applicants must fulfil all identity verification requirements AND prove
ownership of the email address to be identified in the certificate. …
Back contact using the declared email address and or third party
corroboration is undertaken as part of the enrolment process.”
* EV Policy OID: Not requesting EV treatment at this time.
* Test Websites: https://www.trustis.com/
* CRL:
http://www.trustis.com/pki/fps/crl/fpsder.crl
http://www.trustis.com/pki/trustis-ssl/crl/ee.crl (NextUpdate: 24 hours)
** CP section 4.4.9: CRL for end-entity certs is scheduled at least
every 24 hours.
* OCSP: Not provided
* Audit: Audits have been performed by KPMG according to the WebTrust CA
criteria. The audit report is posted on the cert.webtrust.org website:
https://cert.webtrust.org/ViewSeal?id=1120
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Delegation of Domain / Email validation to third parties
** Registration Authorities are used as per section 1.3.2.3 of the CP.
** Registration Authorities (RAs) are permitted to conduct registrations
for a limited, defined and controlled number and type of end-entities.
The RAs have to operate in compliance with the Certificate Policy (CP)
and Certification Practice Statement (CPS) and also the declared
authentication levels for the Trustis FPS services, which are set at HMG
Authentication Framework Level 2 or higher. These are controlled under
the CP, a variety of internal and third party audits and the specific
contractual relationship.
This begins the discussion of the request from Trustis to add the
“Trustis FPS Root CA” root certificate, and turn on the websites and
email trust bits. At the conclusion of this discussion, I will provide a
summary of issues noted and action items. If there are no outstanding
issues, then this request can be approved. If there are outstanding
issues or action items, then an additional discussion may be needed as
follow-up.
Kathleen
and turn on the websites and email trust bits.
Trustis is a commercial CA operating primarily in the UK and Europe.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=577665
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Trustis
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=587468
Noteworthy points:
* The primary documents are the CP and Minimum Enrolment Requirements.
The documents are in English.
Document Repository: http://www.trustis.com/pki/fpsia/
Minimum Enrolment Requirements:
http://www.trustis.com/pki/fpsia/policy/T-0104-002-ATL-013-Trustis-FPS-Minimum-Enrolment-Requirements-V3_0.pdf
Certificate Policy:
http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
Issuing Authority PKI Disclosure Statement:
http://www.trustis.com/pki/fpsia/policy/disclosure.htm
Subscriber Agreement:
http://www.trustis.com/pki/fpsia/policy/subscriber-agreement.htm
* CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=268357
* This root signs internally-operated Issuing CAs that sign end-entity
certs.
** The Trustis FPS Enterprise Authority is the subCA used for issuing
general SSL certificates.
** The Trustis DTP Issuing Authority does not issue SSL certificates.
** The Trustis Healthcare Issuing Authority issues SSL certificates to
UK NHS facilities.
* All subCAs issuing certificates must do so in accordance with the UK
Government Authentication Framework - Level 2. This is required for all
certificates from all of the FPS subCAs be they individual or SSL. In
the case of SSL, this means certs issued are of level 3 or higher.
Domains are validated but a number of other criteria relating to the
organization and the individual representing the organization must also
be satisfied.
UK Government Authentication Framework (GAF) – HMG Minimum Requirements
for Verification:
** Individuals:
http://www.cabinetoffice.gov.uk/media/252559/regindividualsv2.pdf
** Organizations:
http://www.cabinetoffice.gov.uk/media/252565/registra_orgs_v2.pdf
* The request is to turn on the Websites and Email trust bits.
* The following quotes are from the Minimum Enrolment Requirements
document:
** “Trustis FPS issues certificates to a number of levels of assurance
and authentication. In all cases certificates issued shall fulfil the
Standards of HMG Assurance Framework, specifically:
- HMG Minimum Requirements for the Verification of the Identity of
Individuals V2
- HMG Minimum Requirements for the Verification of the Identity of
Organisations V2 at level two.”
** “Note that a formal documented existing relationship with the RA may
be used in lieu of / with other evidence if the RA already has strong
confidence in the identity of the registrant organisation. Underlying
identification checks must have been previously performed and it is
essential to ensure that information used is up-to-date.”
** For Organization Representative, Type of Evidence Required:
“General person acceptable evidence Plus:
- organisational acceptable evidence
- evidence of affiliation to the organisation
- evidence of authority to act on behalf of the organisation
- verification of the representative through "back contact" with the
organization”
** “The registration data for the domain is collected from approved
and/or third party public sources (WHOIS) and corroborated against the
information verified as part of the individual or organisation
registration submitted in the application.
… Where third party or public evidence does not provide corroboration of
ownership of a domain, or an organisation or individual controls a
domain not registered with it. Certified written evidence of
ownership/control must be provided. This is verified and/or corroborated
with the registered owner of the domain.”
** “Certificates are not issued on the basis of email address only.
Applicants must fulfil all identity verification requirements AND prove
ownership of the email address to be identified in the certificate. …
Back contact using the declared email address and or third party
corroboration is undertaken as part of the enrolment process.”
* EV Policy OID: Not requesting EV treatment at this time.
* Test Websites: https://www.trustis.com/
* CRL:
http://www.trustis.com/pki/fps/crl/fpsder.crl
http://www.trustis.com/pki/trustis-ssl/crl/ee.crl (NextUpdate: 24 hours)
** CP section 4.4.9: CRL for end-entity certs is scheduled at least
every 24 hours.
* OCSP: Not provided
* Audit: Audits have been performed by KPMG according to the WebTrust CA
criteria. The audit report is posted on the cert.webtrust.org website:
https://cert.webtrust.org/ViewSeal?id=1120
Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):
* Delegation of Domain / Email validation to third parties
** Registration Authorities are used as per section 1.3.2.3 of the CP.
** Registration Authorities (RAs) are permitted to conduct registrations
for a limited, defined and controlled number and type of end-entities.
The RAs have to operate in compliance with the Certificate Policy (CP)
and Certification Practice Statement (CPS) and also the declared
authentication levels for the Trustis FPS services, which are set at HMG
Authentication Framework Level 2 or higher. These are controlled under
the CP, a variety of internal and third party audits and the specific
contractual relationship.
This begins the discussion of the request from Trustis to add the
“Trustis FPS Root CA” root certificate, and turn on the websites and
email trust bits. At the conclusion of this discussion, I will provide a
summary of issues noted and action items. If there are no outstanding
issues, then this request can be approved. If there are outstanding
issues or action items, then an additional discussion may be needed as
follow-up.
Kathleen
Kathleen Wilson
Jan 27, 2012, 7:37:38 PM1/27/12
to mozilla-dev-s...@lists.mozilla.org
On 1/10/12 2:19 PM, Kathleen Wilson wrote:
> Trustis has applied to add the “Trustis FPS Root CA” root certificate,
> and turn on the websites and email trust bits.
>
> Trustis is a commercial CA operating primarily in the UK and Europe.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=577665
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Trustis
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=587468
>
Would at least two people please review and comment on this root
> Trustis has applied to add the “Trustis FPS Root CA” root certificate,
> and turn on the websites and email trust bits.
>
> Trustis is a commercial CA operating primarily in the UK and Europe.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=577665
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Trustis
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=587468
>
inclusion request from Trustis?
I will greatly appreciate your input.
Kathleen
Kathleen Wilson
Jan 30, 2012, 2:10:02 PM1/30/12
to mozilla-dev-s...@lists.mozilla.org
On 1/28/12 1:25 PM, Bernd Kirsig wrote:
> Their CPS is not publicly available.
> On my opinion this is a critical issue.
Bernd, Thanks for taking a look at this request.
Their Certificate Policy is publicly available:
http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
Why must their CPS also be publicly available?
CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate
Policy and/or Certification Practice Statement through an
appropriate and readily accessible online means that is available on a
24x7 basis."
>
> And the reference to the minimum enrollment requirements points to 2
> documents which are not under their control.
> This looks problematic to me.
>
The enrollment Requirements link on http://www.trustis.com/pki/fpsia/
provides a document that appears to be owned and copywrited by Trustis.
Perhaps I'm misunderstanding?
Kathleen
> Their CPS is not publicly available.
> On my opinion this is a critical issue.
Bernd, Thanks for taking a look at this request.
Their Certificate Policy is publicly available:
http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
Why must their CPS also be publicly available?
CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate
Policy and/or Certification Practice Statement through an
appropriate and readily accessible online means that is available on a
24x7 basis."
>
> And the reference to the minimum enrollment requirements points to 2
> documents which are not under their control.
> This looks problematic to me.
>
The enrollment Requirements link on http://www.trustis.com/pki/fpsia/
provides a document that appears to be owned and copywrited by Trustis.
Perhaps I'm misunderstanding?
Kathleen
Peter Kurrasch
Jan 30, 2012, 7:52:55 PM1/30/12
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
I took a look at the cert and their web site. I don't understand why they
hide their root certs several levels deep. In the case of this FPS root I
have to use an https link--which uses the FPS root as the root for that
chain! I don't know if this is in conflict with any policies (Mozilla or
otherwise) but I think it should be. Any user should be able to reasonably
find the root certs of any CA (without https) and examine them independent
of what may (or may not) be already in use by a browser.
I guess for that matter I would be interested in knowing why I can't find a
link from the main page of their site to the policy docs (anything under
/pki/fpsia/policy) ? Maybe this is what Bernd was getting at? Again, I
don't know this disqualifies them from inclusion but I think a user
advocate would expect/demand that such info be readily available.
Also, I don't see any link on their site for the .crl file. The policy
disclosure form itself mentions that a CRL will be available but doesn't
include a direct link right there...?
Regarding the requested trust bits (websites and email), I would like to
see a Key Usage extension added to the FPS root certificate. Yes, this
would require a re-issue of the cert but certainly this is not impossible?
I mean, it's not like I'm asking for a CN= field to be added! :-)
Finally, their document T-0104-002-ATL-013...V3_0.pdf mentions "HMG
Minimum...for Individuals" and "HMG Minimum...Organisations" but I have no
clue what is meant by "HMG". I think this is the other point Bernd was
trying to raise? I mean their minimum requirements document says to look
in other minimum requirements documents?
On Mon, Jan 30, 2012 at 1:10 PM, Kathleen Wilson <kwi...@mozilla.com>wrote:
> On 1/28/12 1:25 PM, Bernd Kirsig wrote:
>
>> Their CPS is not publicly available.
>> On my opinion this is a critical issue.
>>
>
> Bernd, Thanks for taking a look at this request.
>
> Their Certificate Policy is publicly available:
> http://www.trustis.com/pki/**fpsia/policy/T-FPS-CP-V1-04.**pdf<http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf>
> dev-security-policy mailing list
> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>
hide their root certs several levels deep. In the case of this FPS root I
have to use an https link--which uses the FPS root as the root for that
chain! I don't know if this is in conflict with any policies (Mozilla or
otherwise) but I think it should be. Any user should be able to reasonably
find the root certs of any CA (without https) and examine them independent
of what may (or may not) be already in use by a browser.
I guess for that matter I would be interested in knowing why I can't find a
link from the main page of their site to the policy docs (anything under
/pki/fpsia/policy) ? Maybe this is what Bernd was getting at? Again, I
don't know this disqualifies them from inclusion but I think a user
advocate would expect/demand that such info be readily available.
Also, I don't see any link on their site for the .crl file. The policy
disclosure form itself mentions that a CRL will be available but doesn't
include a direct link right there...?
Regarding the requested trust bits (websites and email), I would like to
see a Key Usage extension added to the FPS root certificate. Yes, this
would require a re-issue of the cert but certainly this is not impossible?
I mean, it's not like I'm asking for a CN= field to be added! :-)
Finally, their document T-0104-002-ATL-013...V3_0.pdf mentions "HMG
Minimum...for Individuals" and "HMG Minimum...Organisations" but I have no
clue what is meant by "HMG". I think this is the other point Bernd was
trying to raise? I mean their minimum requirements document says to look
in other minimum requirements documents?
On Mon, Jan 30, 2012 at 1:10 PM, Kathleen Wilson <kwi...@mozilla.com>wrote:
> On 1/28/12 1:25 PM, Bernd Kirsig wrote:
>
>> Their CPS is not publicly available.
>> On my opinion this is a critical issue.
>>
>
> Bernd, Thanks for taking a look at this request.
>
> Their Certificate Policy is publicly available:
>
> Why must their CPS also be publicly available?
>
> CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate Policy
> and/or Certification Practice Statement through an
> appropriate and readily accessible online means that is available on a
> 24x7 basis."
>
>
>
>> And the reference to the minimum enrollment requirements points to 2
>> documents which are not under their control.
>> This looks problematic to me.
>>
>>
> The enrollment Requirements link on http://www.trustis.com/pki/**fpsia/<http://www.trustis.com/pki/fpsia/>provides a document that appears to be owned and copywrited by Trustis.
> Why must their CPS also be publicly available?
>
> CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate Policy
> and/or Certification Practice Statement through an
> appropriate and readily accessible online means that is available on a
> 24x7 basis."
>
>
>
>> And the reference to the minimum enrollment requirements points to 2
>> documents which are not under their control.
>> This looks problematic to me.
>>
>>
> Perhaps I'm misunderstanding?
>
> Kathleen
> ______________________________**_________________
>
> Kathleen
> dev-security-policy mailing list
> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>
David E. Ross
Jan 30, 2012, 9:02:32 PM1/30/12
to mozilla-dev-s...@lists.mozilla.org
On 1/30/12 11:10 AM, Kathleen Wilson wrote [in part]:
> On 1/28/12 1:25 PM, Bernd Kirsig wrote [also in part]:
CPs and CPSs. The word "publish" has the same root as "public". If the
BR does not require both to be published -- made public -- then it is a
large step backwards.
I think Mozilla should require both to be published, that is made public.
Check "publish" at <http://dictionary.reference.com/browse/publish>.
Note not only how the definitions involve making public but also the
word's origin.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
� 1997 by David E. Ross
> On 1/28/12 1:25 PM, Bernd Kirsig wrote [also in part]:
>> Their CPS is not publicly available.
>> On my opinion this is a critical issue.
>
> Bernd, Thanks for taking a look at this request.
>
> Their Certificate Policy is publicly available:
> http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
>
> Why must their CPS also be publicly available?
>
> CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate
> Policy and/or Certification Practice Statement through an
> appropriate and readily accessible online means that is available on a
> 24x7 basis."
The "WebTrust Program for Certification Authorities" discusses published
>> On my opinion this is a critical issue.
>
> Bernd, Thanks for taking a look at this request.
>
> Their Certificate Policy is publicly available:
> http://www.trustis.com/pki/fpsia/policy/T-FPS-CP-V1-04.pdf
>
> Why must their CPS also be publicly available?
>
> CAB Forum BR 8.2.2: "The CA SHALL publicly disclose its Certificate
> Policy and/or Certification Practice Statement through an
> appropriate and readily accessible online means that is available on a
> 24x7 basis."
CPs and CPSs. The word "publish" has the same root as "public". If the
BR does not require both to be published -- made public -- then it is a
large step backwards.
I think Mozilla should require both to be published, that is made public.
Check "publish" at <http://dictionary.reference.com/browse/publish>.
Note not only how the definitions involve making public but also the
word's origin.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
� 1997 by David E. Ross
Steve Roylance
Jan 30, 2012, 9:17:43 PM1/30/12
to mozilla-dev-s...@lists.mozilla.org
Hi all.
I think the confusion here may stem from the fact that the authority
behind a CP may be different to the authority behind a CPS. i.e. a CA
could be a CA for both of the documents or either of the documents (in
cross signing activities etc)
I could make a motion within the CABForum to correct this text in the BRs
and make it clear that a CA should publish the items it is an authority
for.
Would that help?
Steve
>_______________________________________________
>dev-security-policy mailing list
>dev-secur...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-security-policy
I think the confusion here may stem from the fact that the authority
behind a CP may be different to the authority behind a CPS. i.e. a CA
could be a CA for both of the documents or either of the documents (in
cross signing activities etc)
I could make a motion within the CABForum to correct this text in the BRs
and make it clear that a CA should publish the items it is an authority
for.
Would that help?
Steve
>dev-security-policy mailing list
>dev-secur...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-security-policy
r...@northfell.com
Feb 6, 2012, 12:54:45 PM2/6/12
to mozilla-dev-s...@lists.mozilla.org
Hi all,
Thanks for raising the above points and I apologise it's taken a few
days to get back to you.
In reference to the question on publication of the CP/CPS, we think
this is just a matter of terminology some publish full details under
“CP” and others under “CPS”. Presumably, the important thing is that
all the information is made available.
With respect to Enrolment Requirements. We do reference the HMG
Guidelines, which are widely used identity assurance standards,
created as the result of a major public sector risk analysis for
identity services. However, our document, which is under our full
control, contains the complete set of criteria used for enrolment
without the need reference other documentation. (FYI, HMG = Her
Majesty’s Government.)
The link in our Mozilla application provides a direct HTTP link to our
root certificate and we make it available via a wide number of HTTP
links from our various public services. If Peter Kurrasch can let us
know about the particular link he found we will address it.
As to for our policy docs, this is simply a matter of convenience and
tidiness. We provide links to full policy document sets for each of
the public services (under the “terms” or “certificate policy” tabs).
Our model is that a service user can get to the full set of
documentation easily. If there is somewhere that this is not possible
perhaps Peter can let us know. We also provide links to policies in
all our end user certificates.
We are not aware that there is a requirement for a CRL link to be
included in a PKI Disclosure Statement. There is a direct link to the
CRL provided in our application to Mozilla. All our end entity and
Issuing Authority certificates include a CRL DP which can be used to
access the relevant CRL.
We are a little unsure of the issue Peter raises with regard to Key
Usage. Our root was developed and initiated some time ago; it fully
satisfies specific requirements of customers, is widely deployed and
has a whole range of approvals, audits and certifications. A change
would be impractical as it would impact all these.
Rob
Thanks for raising the above points and I apologise it's taken a few
days to get back to you.
In reference to the question on publication of the CP/CPS, we think
this is just a matter of terminology some publish full details under
“CP” and others under “CPS”. Presumably, the important thing is that
all the information is made available.
With respect to Enrolment Requirements. We do reference the HMG
Guidelines, which are widely used identity assurance standards,
created as the result of a major public sector risk analysis for
identity services. However, our document, which is under our full
control, contains the complete set of criteria used for enrolment
without the need reference other documentation. (FYI, HMG = Her
Majesty’s Government.)
The link in our Mozilla application provides a direct HTTP link to our
root certificate and we make it available via a wide number of HTTP
links from our various public services. If Peter Kurrasch can let us
know about the particular link he found we will address it.
As to for our policy docs, this is simply a matter of convenience and
tidiness. We provide links to full policy document sets for each of
the public services (under the “terms” or “certificate policy” tabs).
Our model is that a service user can get to the full set of
documentation easily. If there is somewhere that this is not possible
perhaps Peter can let us know. We also provide links to policies in
all our end user certificates.
We are not aware that there is a requirement for a CRL link to be
included in a PKI Disclosure Statement. There is a direct link to the
CRL provided in our application to Mozilla. All our end entity and
Issuing Authority certificates include a CRL DP which can be used to
access the relevant CRL.
We are a little unsure of the issue Peter raises with regard to Key
Usage. Our root was developed and initiated some time ago; it fully
satisfies specific requirements of customers, is widely deployed and
has a whole range of approvals, audits and certifications. A change
would be impractical as it would impact all these.
Rob
Peter Kurrasch
Feb 7, 2012, 8:40:18 PM2/7/12
to r...@northfell.com, mozilla-dev-s...@lists.mozilla.org
Embedded below...
On Mon, Feb 6, 2012 at 11:54 AM, <r...@northfell.com> wrote:
> The link in our Mozilla application provides a direct HTTP link to our
> root certificate and we make it available via a wide number of HTTP
> links from our various public services. If Peter Kurrasch can let us
> know about the particular link he found we will address it.
>
I did use the Mozilla application link to grab the cert but I was hoping to
find it just as easily from the main trustis website. The part that I was
not expecting is when I click on the "SSL trustis-ssl" icon on the right
side. All the other icon-links use just http: but this one for whatever
reason uses https--and https rooted with the trustis fps cert for which I'm
searching.
Once on that page I chose the Help link (don't remember if I found anything
useful from the other links) and then under the question "why does website
say untrusted" question, I get the following link:
https://trustis-ssl.trustis.com/support/ssl-server/cert-install/index.html
Just to provide a comparison between the Trustis way and what I would
consider a "best practice" please take a look at what GeoTrust is doing on
their website:
https://www.geotrust.com/resources/
On it, you'll see they not only have a "Resources" link front-and-center
but on the resources page you have links to everything you might want
(propaganda and all!). I wish everyone would make their info so readily
accessible--and that's why I mention it here.
We are a little unsure of the issue Peter raises with regard to Key
> Usage. Our root was developed and initiated some time ago; it fully
> satisfies specific requirements of customers, is widely deployed and
> has a whole range of approvals, audits and certifications.
Good!
> A change
> would be impractical as it would impact all these.
>
Mmmm...maybe not. I don't think this is any different that re-issuing the
cert with an updated expiration date. An extension would be added but
subject/issuer remain the same; public/private keys are the same; dates
could even be the same. (I don't know if adding an extension in the manner
I suggest would necessarily affect audits/certifications, so please let me
know.)
Further, issuing a new cert for inclusion in a client-side trust store does
not mean all your customers must immediately adopt and include the cert in
their server configs. In fact, I think it's better if their servers are
configured *without* this root cert in the chain. That is, refer to it as
an issuer but don't send it during SSL cert exchange. Some clients work
better without it (that's been my experience anyway).
In any event, take a look at the UTN-USERFirst-Hardware certificate. In it
you'll see an extension for "Enhanced Key Usage" with the following:
Server Authentication (1.3.6.1.5.5.7.3.1)
IP security end system (1.3.6.1.5.5.7.3.5)
IP security tunnel termination (1.3.6.1.5.5.7.3.6)
IP security user (1.3.6.1.5.5.7.3.7)
(as a reference, check out: http://www.oid-info.com/get/1.3.6.1.5.5.7.3)
I think this is a good thing to add--and again, I wish more issuers would.
It's just another way the client-side can ensure that the cert and its
descendants are all playing nicely.
Hope this helps...?
Thanks.
On Mon, Feb 6, 2012 at 11:54 AM, <r...@northfell.com> wrote:
> The link in our Mozilla application provides a direct HTTP link to our
> root certificate and we make it available via a wide number of HTTP
> links from our various public services. If Peter Kurrasch can let us
> know about the particular link he found we will address it.
>
find it just as easily from the main trustis website. The part that I was
not expecting is when I click on the "SSL trustis-ssl" icon on the right
side. All the other icon-links use just http: but this one for whatever
reason uses https--and https rooted with the trustis fps cert for which I'm
searching.
Once on that page I chose the Help link (don't remember if I found anything
useful from the other links) and then under the question "why does website
say untrusted" question, I get the following link:
https://trustis-ssl.trustis.com/support/ssl-server/cert-install/index.html
Just to provide a comparison between the Trustis way and what I would
consider a "best practice" please take a look at what GeoTrust is doing on
their website:
https://www.geotrust.com/resources/
On it, you'll see they not only have a "Resources" link front-and-center
but on the resources page you have links to everything you might want
(propaganda and all!). I wish everyone would make their info so readily
accessible--and that's why I mention it here.
We are a little unsure of the issue Peter raises with regard to Key
> Usage. Our root was developed and initiated some time ago; it fully
> satisfies specific requirements of customers, is widely deployed and
> has a whole range of approvals, audits and certifications.
> A change
> would be impractical as it would impact all these.
>
cert with an updated expiration date. An extension would be added but
subject/issuer remain the same; public/private keys are the same; dates
could even be the same. (I don't know if adding an extension in the manner
I suggest would necessarily affect audits/certifications, so please let me
know.)
Further, issuing a new cert for inclusion in a client-side trust store does
not mean all your customers must immediately adopt and include the cert in
their server configs. In fact, I think it's better if their servers are
configured *without* this root cert in the chain. That is, refer to it as
an issuer but don't send it during SSL cert exchange. Some clients work
better without it (that's been my experience anyway).
In any event, take a look at the UTN-USERFirst-Hardware certificate. In it
you'll see an extension for "Enhanced Key Usage" with the following:
Server Authentication (1.3.6.1.5.5.7.3.1)
IP security end system (1.3.6.1.5.5.7.3.5)
IP security tunnel termination (1.3.6.1.5.5.7.3.6)
IP security user (1.3.6.1.5.5.7.3.7)
(as a reference, check out: http://www.oid-info.com/get/1.3.6.1.5.5.7.3)
I think this is a good thing to add--and again, I wish more issuers would.
It's just another way the client-side can ensure that the cert and its
descendants are all playing nicely.
Hope this helps...?
Thanks.
Peter Kurrasch
Feb 7, 2012, 8:53:05 PM2/7/12
to r...@northfell.com, mozilla-dev-s...@lists.mozilla.org
Quick update: when I mentioned the UTN-USERFirst-Hardware certificate, I
meant the self-signed cert with an expiration date of 2019. In my special
collection of certs I have one which is tied to the AddTrust External CA
Root. That cert doesn't have the "Enhanced Key Usage" extension that I
mention (not sure why).
Regardless, I'm attaching the self-signed cert to this email so you can see
specifically what I'm talking about.
meant the self-signed cert with an expiration date of 2019. In my special
collection of certs I have one which is tied to the AddTrust External CA
Root. That cert doesn't have the "Enhanced Key Usage" extension that I
mention (not sure why).
Regardless, I'm attaching the self-signed cert to this email so you can see
specifically what I'm talking about.
r...@northfell.com
Feb 10, 2012, 7:51:59 AM2/10/12
to mozilla-dev-s...@lists.mozilla.org
Thanks to Peter for his further comments; he has gone to the trouble
of fleshing out the points he raised in the context of our responses.
I have where applicable represented the comments from Peter with my
responses.
Access to root certificates:-
Using SSL to obtain a root certificate is not unique to Trustis.
However, following raising this, with the benefit of your feedback
(thanks), this will be put through our product improvement process for
our SSL Service so that the Root can be obtained via HTTP.
Linking from the Home Page:-
I took this to our marketing dept who control our website, via a
product improvement proposal. The approach we take on our website is a
service and user centric one rather than generic and we have had no
customer issues related to access to the Root certificate reported. I
have provided the Geotrust reference you used along with your
comments. We will keep this under review and may decide to implement
it if circumstances change.
Change to Root CA Profile:-
Peter, thanks, the issue is clearer now. I spoke with our Policy
Authority about this. We are confident that a change to the root
certificate profile would have a disproportionate impact on approvals
and our arrangements with customers.
Also can I point out that our certificates are used for much more than
SSL and the way trust chains are managed is many and varied. It is
clear you would prefer more certificate issuers to use EKU. Perhaps
there should be a review of those that operate and manage trust
anchors and how they handle EKU issues? However I'm not sure this
particular discussion is the right forum.
Regards, Rob
of fleshing out the points he raised in the context of our responses.
I have where applicable represented the comments from Peter with my
responses.
Access to root certificates:-
Using SSL to obtain a root certificate is not unique to Trustis.
However, following raising this, with the benefit of your feedback
(thanks), this will be put through our product improvement process for
our SSL Service so that the Root can be obtained via HTTP.
Linking from the Home Page:-
I took this to our marketing dept who control our website, via a
product improvement proposal. The approach we take on our website is a
service and user centric one rather than generic and we have had no
customer issues related to access to the Root certificate reported. I
have provided the Geotrust reference you used along with your
comments. We will keep this under review and may decide to implement
it if circumstances change.
Change to Root CA Profile:-
Peter, thanks, the issue is clearer now. I spoke with our Policy
Authority about this. We are confident that a change to the root
certificate profile would have a disproportionate impact on approvals
and our arrangements with customers.
Also can I point out that our certificates are used for much more than
SSL and the way trust chains are managed is many and varied. It is
clear you would prefer more certificate issuers to use EKU. Perhaps
there should be a review of those that operate and manage trust
anchors and how they handle EKU issues? However I'm not sure this
particular discussion is the right forum.
Regards, Rob
Kathleen Wilson
Mar 16, 2012, 8:36:47 PM3/16/12
to mozilla-dev-s...@lists.mozilla.org
On 1/10/12 2:19 PM, Kathleen Wilson wrote:
> Trustis has applied to add the “Trustis FPS Root CA” root certificate,
> and turn on the websites and email trust bits.
>
> Trustis is a commercial CA operating primarily in the UK and Europe.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=577665
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Trustis
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=587468
>
Thanks to all of you who have reviewed and commented on this request
> and turn on the websites and email trust bits.
>
> Trustis is a commercial CA operating primarily in the UK and Europe.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=577665
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Trustis
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=587468
>
from Trustis to add the “Trustis FPS Root CA” root certificate, and turn
on the websites and email trust bits.
Here follows a summary of the discussion.
on the websites and email trust bits.
A question was asked about there being a CP and not a CPS. Trustis
responded that all the requisite information has been provided, and
there is just a terminology difference in that some CAs publish all
details in the CP and others do so in the CPS. I have seen this too, so
when I evaluate CAs, I look to see if the information is in either the
CP or CPS, and often times I’ve seen the CA combines all of the
information into one document.
Trustis stated that they provide links to full policy document sets for
each of their public services on their website. They also provide links
to their policies in their end user certificates, for instance:
http://www.trustis.com/pki/trustis-ssl/standard/
Trustis provides both an https and a non-https link to their root
certificate:
http://www.trustis.com/roots/fps/certs/fpsroot.crt
Trustis pointed out that all of their certificates have CRL distribution
points in them. For example, in an end-entity cert:
http://www.trustis.com/pki/trustis-ssl/crl/ee.crl and in an intermediate
cert: http://www.trustis.com/pki/fps/crl/ia.crl
I have imported both of these into my Firefox browser without error.
There was a request to update the FPS root certificate to add the Key
Usage extension, because only the websites and email trust bits are
being asked for. Trustis responded that their certificates are used for
more than SSL and S/MIME, but those are the trust bits that they need
turned on in Mozilla products.
During the course of this discussion, Trustis updated the bug to provide
a link to their recent audit statement:
https://cert.webtrust.org/ViewSeal?id=1250
It is my opinion that all of the questions that have been raised in this
discussion have received an appropriate response. There are no action
items resulting from this discussion.
I have requested in the bug that Trustis respond to the recent CA
Communication, and I will track that response in the bug before
approving this request.
If there are no further comments on this request from Trustis to add the
“Trustis FPS Root CA” root certificate, and turn on the websites and
email trust bits, then I propose closing this discussion and
recommending approval in the bug.
Thanks,
Kathleen
Kathleen Wilson
Mar 26, 2012, 7:18:18 PM3/26/12
to mozilla-dev-s...@lists.mozilla.org
On 3/16/12 5:36 PM, Kathleen Wilson wrote:
> It is my opinion that all of the questions that have been raised in this
> discussion have received an appropriate response. There are no action
> items resulting from this discussion.
>
> I have requested in the bug that Trustis respond to the recent CA
> Communication, and I will track that response in the bug before
> approving this request.
>
> If there are no further comments on this request from Trustis to add the
> “Trustis FPS Root CA” root certificate, and turn on the websites and
> email trust bits, then I propose closing this discussion and
> recommending approval in the bug.
>
I am now closing this discussion.Thanks again to all of you who
> It is my opinion that all of the questions that have been raised in this
> discussion have received an appropriate response. There are no action
> items resulting from this discussion.
>
> I have requested in the bug that Trustis respond to the recent CA
> Communication, and I will track that response in the bug before
> approving this request.
>
> If there are no further comments on this request from Trustis to add the
> “Trustis FPS Root CA” root certificate, and turn on the websites and
> email trust bits, then I propose closing this discussion and
> recommending approval in the bug.
>
contributed to this discussion.
Trustis has responded to the recent CA Communication.
https://bugzilla.mozilla.org/show_bug.cgi?id=577665#c29
There are no open action items resulting from this discussion.
I will recommend approval in the bug for this request to add the
“Trustis FPS Root CA” root certificate, and turn on the websites and
email trust bits.
https://bugzilla.mozilla.org/show_bug.cgi?id=577665
email trust bits.
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages