Peter, > -----Original Message----- > From: Peter Sylvester > > On 09/18/2013 09:53 AM, Eisenacher, Patrick wrote: > >> -----Please also note that adding extensions to a certificate request > usually doesn't make any sense, as those get added to the certificate solely > by the certificate issuer's grace. > >> > >> > hi, > > I seem to disagree, well, "usually" saves you :-) > > Setting your email address or a server name into the subjectaltname, how do > you do this otherwise? > setting commonname for the server, ok, setting an email attribute that will > them > be copied by the CA (and the email removed because it is depracated)? > > Setting ALL extensions makes a lot of sense, IMO a CA should not add and > modify thngs, a CA > should *validate* them. The requester indicates what should be in the cert. > > The current practice by some registrars to add example.org as another name > when > you have ordered www.example.com etc may be nice for some people, but > annoying > for others, at best a surprise when policy and practice documents do not > even mention > these behaviours.
you give valid exceptions, that's why I said usually. Those exceptions all serve to identiy the subject. It doesn't matter how these infos reach the CA, be it in-band or out-of-band. And it shouldn't matter how the request encodes that information in case the info is given in-band. The CA issues certificates conforming to a specific certificate profile. If the CA issues different types of certificates, it has a certificate profile for each type. The requestor can only choose between the types, ie. client or server cert, but not choose the structure of the certificate. Since a certificate is complex, PKI-knowledge is rare and the CA is liable for it, I don't think that letting your customers determine extensions or their criticality is a good idea. Furthermore, the CA's QA wouldn't be able to validate that their system works as expected and issues sound certificates that conform to PKIX or some other profile. Patrick Eisenacher
