Changes

Jump to: navigation, search

CA/Required or Recommended Practices

556 bytes removed, 18:59, 1 September 2010
Notes for future work
* What (if anything) should we do regarding the use of non US-ASCII character sets in certs? To what extent is this supported today in NSS and by CAs? This whole problem seems analogous to the IDN problem.
** Excluding the IDN problem (on which I comment under "Document Handling of IDNs in CP/CPS"), care should be taken to avoid setting technical requirements more stringent than the X.509 specifications. If X.509 permits non-US-ASCII characters in certificates and if NSS and the Mozilla products that use it can operate correctly in the presence of such characters, they should be permitted. On the other hand, if non-US-ASCII characters cause technical problems for NSS or the Mozilla products that use it, that is already addressed under item #4 (after the first two bullets) in the existing policy. Of course, it might be appropriate to add a new bullet in the second set of bullets under item #4 to state explicitly that certificates must not contain any characters that cause software failures or security vulnerabilities in Mozilla products. As an alternative, characters might be limited to those used in languages for which Mozilla products have been localized.
 
''proposal from Viktor Varga:''
''the exception when a natural person owns a domain name is not handled in any RFC. Its right, that the DNS to the CN is a deprecated solution, but the usage of the DNS in CN field is still popular.''
''The question, how to display a natural person in a certificate.''
''In EV it is solved, because EV can be bought only by organisation.''
''CN cant be used, and the O field means organisation, not Individual.''
 
''My proposal can be read here:''
''(please move it to the right place, edit or delete it if not conforms.''
Confirm, administrator
5,526
edits

Navigation menu