Policy change request : Only include *validated* user supplied elements inside certificates
Jean-Marc Desperrier
related vulnerability in February, but did not do it immediately since I
could not find the time for a full explanation.
See here for the description of it if you need :
http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/
There hasn't been much discussion here about this vulnerability, whilst
I think they is a lesson to get from it.
One easy thing to say would be that this is all the fault of Apple, that
they should not have been stupid enough to include every CA in their
trust path, and then just stop there. IMO the consequence is that the
same thing will happen all the same the next time. Errors always happen,
and a system can only be said secure when it makes the best to insure
people don't shoot themselves in the foot.
With that in mind, it's time to see if something could not have been at
the PKI level to make such an error less likely.
And it then becomes quite obvious that the PKI weakness that made the
attack possible at all is that this free email certificate included an
element that :
- was supplied by the requester
- wasn't in any way validated by the CA, per it's policy
And I think that the lesson to get from this attack is that this should
not exist.
Free email certificates only validate an email address *therefore* they
should only include that email as a user specific element.
Only validated elements should exist inside a certificate, anything that
was not verified as correct has nothing to do there (a side-effect is
that is would be obvious that alternative names need to be validated
just as well as the subject, as it seems some CAs have issued SSL certs
where they were not correctly validated).
So I think Mozilla Foundation should incorporate this requirement in
it's CA inclusion policy, and should also try to work with already
included CA so that existing policies and process are modified to comply
with it.
The question left is, what should then those CA put in those CN and I
will not try to bring here a definitive answer to that (a fixed text for
all certificates, a copy of the email ?)
Kathleen Wilson
> So I think Mozilla Foundation should incorporate this requirement in
> it's CA inclusion policy, and should also try to work with already
> included CA so that existing policies and process are modified to comply
> with it.
I've added the following to the "Other considerations when updating the
CA Certificate Policy" section of the Potentially Problematic Practices
page.
https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates
Validate all Data included in Certificates
Only data that has been verified to be correct should be included in a
certificate. All information that is supplied by the requester must be
verified to be correct before it may be included in the certificate.
Alternative names need to be validated just as well as the subject. For
example, if only the email address of the certificate subscriber is
verified, then only the email address should be included in the
certificate.
Kathleen
Jean-Marc Desperrier
> I've added the following to the "Other considerations when updating the
> CA Certificate Policy" section of the Potentially Problematic Practices
> page.
> https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates
Thank you that's great.
In order to try to stir some controversy on this issue (that's a bit
disappointing a suggestion gets directly approved without discussion ;-)
), I'll add the remarks that Startcom already complies to this policy,
it puts "StartCom Free Certificate Member" as the subject of it's free
mail certs.
> [...]
> Alternative names need to be validated just as well as the subject. For
> example, if only the email address of the certificate subscriber is
> verified, then only the email address should be included in the
> certificate.
Suggestion of wording change :
For example, for SSL certificates, alternative names need to be
validated just as well as the subject. And for email certificates, if
only the email address of the certificate subscriber is verified, then
the CN should not include any unverified element the subscriber supplied.
Eddy Nigg
>> I've added the following to the "Other considerations when updating the
>> CA Certificate Policy" section of the Potentially Problematic Practices
>> page.
>> https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates
>>
>
> Thank you that's great.
>
> In order to try to stir some controversy on this issue (that's a bit
> disappointing a suggestion gets directly approved without discussion
> ;-) ), I'll add the remarks that Startcom already complies to this
> policy, it puts "StartCom Free Certificate Member" as the subject of
> it's free mail certs.
With that I'd suggest to allow for some flexibility without making any
claims regarding validated details. CAs have traditionally used some
phrase to indicate the trust level or similar disclaimers in one of the
field of the DN.
However for server certificates I'd like to see the country field
allowed to be populated with a two letter country code for statistical
purpose (mostly with Netcraft). It's probably an exception most CAs want.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> that's a bit disappointing a suggestion gets directly approved
> without discussion
Please note that it's not approved for the Mozilla CA Certificate
Policy. It's in the "Other considerations when updating the CA
Certificate Policy" section of the Potentially Problematic Practices
wiki page. That means that it will be reviewed and considered by CAs who
are submitting root inclusion requests, but is not grounds for denying
their request. It also means that at some later, undefined date there
will be further discussion to determine if this item should be included
in the actual policy and exactly what text would be added.
Adding things to that wiki page is easy. Updating the actual Mozilla CA
Certificate Policy is a much more difficult and time consuming endeavor.
> Suggestion of wording change :
> For example, for SSL certificates, alternative names need to be
> validated just as well as the subject. And for email certificates, if
> only the email address of the certificate subscriber is verified, then
> the CN should not include any unverified element the subscriber supplied.
Done.
Please see the new text in
https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates
From Eddy:
> CAs have traditionally used some phrase to indicate the trust level
> or similar disclaimers in one of the field of the DN.
>
> However for server certificates I'd like to see the country field
> allowed to be populated with a two letter country code for
> statistical purpose (mostly with Netcraft). It's probably an
> exception most CAs want.
I think the new text allows for both of these cases. Correct?
Thanks,
Kathleen
Jean-Marc Desperrier
> It's in the "Other considerations when updating the CA Certificate
> Policy" section of the Potentially Problematic Practices wiki page. That
> means that it will be reviewed and considered by CAs who are submitting
> root inclusion requests, but is not grounds for denying their request.
Is this review an action officially requested from the CA or just
suggested ? Is it requested that they *shall* issue a warning if one of
their practice is in the list, so that it gets discussed in the public
review ?
Anyway I understood it's just flagged as a problematic practice, but
it's a good ground to rise it from now for every new request. In fact I
wonder if until now list of element provided by the requester and
included in the cert has always been properly reviewed.
Kathleen Wilson
During the Information Gathering and Verification phase I specifically
ask the CA to review the Potentially Problematic Practices wiki page and
provide further information for items that are relevant. I also look
through the CP/CPS for indications of these items. The responses are in
the Information Gathering document that I attach to the bug and provide
a link to when I start the public discussion. I also try to call out the
relevant items in the summary that I post to start the discussion.
Varga Viktor
>Only validated elements should exist inside a certificate, anything that
>was not verified as correct has nothing to do there (a side-effect is
>that is would be obvious that alternative names need to be validated
>just as well as the subject, as it seems some CAs have issued SSL certs
>where they were not correctly validated).
Of-course correct CAs are validating the SAN field to. For server certs, with whois, for signer cert, with the email check.
>So I think Mozilla Foundation should incorporate this requirement in
>it's CA inclusion policy, and should also try to work with already
>included CA so that existing policies and process are modified to comply
>with it.
Its a good idea.
You sugest this only for the user specific data, don't you?
For example subject/serialnumber can include a CA specific of a person specific data (a sequence, or an ID connected with one of the natural persons IDs.
>The question left is, what should then those CA put in those CN and I
>will not try to bring here a definitive answer to that (a fixed text for
>all certificates, a copy of the email ?)
We issue them (only from a test CA) with a fixed text int he CN, which has the value, "... test certificate..."
(Our free signer certificates were made for testing purpose only.)
Varga Viktor
Netlock Ltd.
__________ ESET NOD32 Antivirus - V?rusdefin?ci?s adatb?zis: 4937 (20100311) __________
Az ?zenetet az ESET NOD32 Antivirus ellen?rizte.
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Jean-Marc Desperrier
> You sugest this only for the user specific data, don't you?
Yes, indeed.
> For example subject/serialnumber can include a CA specific of a
> person specific data (a sequence, or an ID connected with one of the
> natural persons IDs.
I'm not sure I fully understand what you mean here. I believe you refer
to some numbers that would have no specific meaning for externals
parties. So they would not be a problem directly.