WebTrust, RFC 3647, and ANSI X9.79
Frank Hecker
certificate policy in the next few days, and one of the things I was
thinking about was how to address Ian Grigg's concern about calling out
WebTrust by name as the criteria to be used. If you recall, Ian
suggested modifying the policy language to refer to "published criteria
satisfactory to [the Mozilla Foundation]", along with stating that
"[the] starting point for the criteria is _WebTrust for CA_ criteria".
But I'm wondering if a better approach would be to refer to other
published criteria that are "WebTrust-like", without necessarily
referring to the WebTrust criteria themselves. The most obvious
candidates to come to mind are RFC 3647:
http://www.ietf.org/rfc/rfc3647.txt
and ANSI X9.79:
http://www.x9.org/catalog2.cfm?item_no=%24%23%20%2F%217%20%21O%0A&pub_item=%2334%2A%3B%0A
As I recall, both of these were used as input when the WebTrust criteria
were created. I don't have time at the moment to do a detailed
comparison of the RFC 3647 and X9.79 criteria and how they differ from
the published WebTrust criteria:
http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc
Does anyone know of any web-accessible documents that contain such a
comparison?
Any other comments on using RFC 3647 or X9.79 as the reference criteria
for the policy? (Note that if we do this I personally would prefer to
use RFC 3647 since you don't have to pay USD 50 to get a copy.)
Frank
--
Frank Hecker
hec...@hecker.org
Jyrki Nivala
> I'm going to try and do another revision of the draft Mozilla CA
> certificate policy in the next few days, and one of the things I was
> thinking about was how to address Ian Grigg's concern about calling out
> WebTrust by name as the criteria to be used. If you recall, Ian
> suggested modifying the policy language to refer to "published criteria
> satisfactory to [the Mozilla Foundation]", along with stating that
> "[the] starting point for the criteria is _WebTrust for CA_ criteria".
>
> But I'm wondering if a better approach would be to refer to other
> published criteria that are "WebTrust-like", without necessarily
> referring to the WebTrust criteria themselves. The most obvious
> candidates to come to mind are RFC 3647:
>
> http://www.ietf.org/rfc/rfc3647.txt
>
> and ANSI X9.79:
>
> http://www.x9.org/catalog2.cfm?item_no=%24%23%20%2F%217%20%21O%0A&pub_item=%2334%2A%3B%0A
>
>
> As I recall, both of these were used as input when the WebTrust criteria
> were created. I don't have time at the moment to do a detailed
> comparison of the RFC 3647 and X9.79 criteria and how they differ from
> the published WebTrust criteria:
>
> http://ftp.webtrust.org/webtrust_public/tpafile7-8-03fortheweb.doc
>
> Does anyone know of any web-accessible documents that contain such a
> comparison?
any requirents for the CA. E.g. RFC 3647 only " presents a framework to
assist the writers of certificate policies...Further, this document does
not define a specific CP or CPS. Moreover, in presenting a framework,
this document should be viewed and used as a flexible tool presenting
topics that should be considered of particular relevance to CPs or CPSs,
and not as a rigid formula for producing CPs or CPSs."
If RFC 3647 is going to be used as a criteria Mozilla Foundation should
provide minimum requirements for topics mentioned in RFC 3647, IMHO.
Maybe these could helpful as well:
PKI Assessment Guidelines by American Bar Association
European Telecommunications Standards Institute, "Policy Requirements
for Certification Authorities Issuing Qualified Certificates"
In general I would require a third party audit.
regards,
-Jyrki Nivala
Frank Hecker
> The problem with both RFC 3647 and ANSI X9.79 is that they don't have
> any requirents for the CA. E.g. RFC 3647 only " presents a framework to
> assist the writers of certificate policies...Further, this document does
> not define a specific CP or CPS. Moreover, in presenting a framework,
> this document should be viewed and used as a flexible tool presenting
> topics that should be considered of particular relevance to CPs or CPSs,
> and not as a rigid formula for producing CPs or CPSs."
Thanks for your comments. After reading RFC 3647 more closely I
understand your point: It in effect says "the CA should describe how
they do task X" (where X might be protection of signing keys), but does
not necessarily say "X should be done in a way that meets requirement Y".
I guess I'll have to get a copy of X9.79 to see if it takes the same
approach.
> If RFC 3647 is going to be used as a criteria Mozilla Foundation should
> provide minimum requirements for topics mentioned in RFC 3647, IMHO.
Well, we could draw such requirements from the WebTrust criteria, but
then we might as well reference those criteria directly.
> Maybe these could helpful as well:
> PKI Assessment Guidelines by American Bar Association
I'm familar with this document.
> European Telecommunications Standards Institute, "Policy Requirements
> for Certification Authorities Issuing Qualified Certificates"
I haven't read this document but will check it out.
> In general I would require a third party audit.
That is my proposal: Whatever the criteria are, the CA's conformance to
the criteria should be judged by an independent third party.
Ian G
>
> I guess I'll have to get a copy of X9.79 to see if it takes the same
> approach.
I also think the $50 price tag is indicative. Anything
that can't be posted freely on the MF websites is
unlikely to be useful as a basis for policy. But it
still might give some ideas.
>> If RFC 3647 is going to be used as a criteria Mozilla Foundation
>> should provide minimum requirements for topics mentioned in RFC 3647,
>> IMHO.
>
>
> Well, we could draw such requirements from the WebTrust criteria, but
> then we might as well reference those criteria directly.
Refencing criteria are fine, but that's distinct from
requiring them...
>> In general I would require a third party audit.
>
>
> That is my proposal: Whatever the criteria are, the CA's conformance
> to the criteria should be judged by an independent third party.
>
OK. I personally think that a CA should be capable
of judging better what those criteria should be.
They know more about the business, and they can
be expected to govern it accordingly. Giving them
a throwaway excuse like "we followed the WebTrust
rules to the letter" will get you just that, the letter
of the law, not the spirit of security.
Once we've reached that point, the philosophical
judgement that a CA knows what it is doing, and
can be asked to do it, how we govern that arrangement
is a separate issue. For that we have professional
auditors (KPMGPM), we have expert auditors (David)
and we have user scrutiny (open governance). But
those techniques only kick in when we decide what
it is that they need to audit.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Frank Hecker
> Jyrki Nivala wrote:
>> The problem with both RFC 3647 and ANSI X9.79 is that they don't have
>> any requirents for the CA. E.g. RFC 3647 only " presents a framework
>> to assist the writers of certificate policies...Further, this document
>> does not define a specific CP or CPS. Moreover, in presenting a
>> framework, this document should be viewed and used as a flexible tool
>> presenting topics that should be considered of particular relevance to
>> CPs or CPSs, and not as a rigid formula for producing CPs or CPSs."
>
> Thanks for your comments. After reading RFC 3647 more closely I
> understand your point: It in effect says "the CA should describe how
> they do task X" (where X might be protection of signing keys), but does
> not necessarily say "X should be done in a way that meets requirement Y".
>
> I guess I'll have to get a copy of X9.79 to see if it takes the same
> approach.
I have now acquired and read a copy of X9.79, and in fact X9.79 does
have a set of real CA criteria in Appendix B, "(Normative) Certification
Authority Control Objectives". I have not done a detailed comparison of
X9.79 and the WebTrust for CAs criteria, but based on Appendix D of the
WebTrust criteria it appears that there is a one-to-one correspondence
between most if not all of the X9.79 Appendix B criteria and the
WebTrust criteria.
(The wording of the criteria is slightly different in X9.79 vs.
WebTrust; in X9.79 the detailed criteria are presented as
straightforward "the CA shall do X" requirements, while in WebTrust the
detailed criteria are often presented as "illustrative controls".)
sdavidson
101.456 "Policy requirements for certification authorities issuing qualified
certificates". It is roughly the European equivalent of ANSI X9.79.
Many countries use these standards as part of their voluntary accreditation
schemes - but only a handful of CAs are pursuing those accreditations at
this point.
The commercial WebTrust accreditation (which in fact covers the same turf)
seems to be the most recognised by customers of the CAs.
Bill Burns
[Jumps into the discussion late]
Just in case anyone doesn't know, a common misconception is that
WebTrust is a bunch of rules. It isn't. It is, in fact, a set of
criteria and guidelines.
They don't say "You must encrypt a subscriber's private keys with AES".
They say, "Subscriber private keys stored by the CA are stored in
encrypted form using a cryptographic algorithm and key length based on a
risk assessment and the business requirements of the CA." [WebTrust 2.1.9]
There's nothing about key length or algorithm here.
Having just gone through my 2nd WebTrust evaluation this year I can tell
you that the auditors don't evaluate you against a cookbook of specific
actions. They look for what YOU SAY your actions are, based on your
documented* set of policies and practices.
The WebTrust auditors, in essence, judge you primarily against two things:
- do you do what you claim (in your various documents) you do?; and
- do your policies/procedures cover their list of recommended
policies/procedures?
* - They can't stress this enough in their audit. If a policy or
practice isn't written down, it doesn't exist.
As much of a pain in the arse the nearly 400 WebTrust criteria are, they
do force the CA to run their operational pretty carefully.
<soapbox mode deactivated>
bill
Frank Hecker
> Just in case anyone doesn't know, a common misconception is that
> WebTrust is a bunch of rules. It isn't. It is, in fact, a set of
> criteria and guidelines.
>
> They don't say "You must encrypt a subscriber's private keys with AES".
> They say, "Subscriber private keys stored by the CA are stored in
> encrypted form using a cryptographic algorithm and key length based on a
> risk assessment and the business requirements of the CA." [WebTrust 2.1.9]
>
> There's nothing about key length or algorithm here.
Right, as I think I've mentioned previously the specific discussions in
WebTrust re key lengths, algorithms, etc., are in the "illustrative
controls" text, which is just that, "illustrative" as opposed to
"mandatory".
For the record, I think that this is a good approach.