| | | | | | | | |
|
|
|
You're here: Home |
At 8:25 AM +1000 4/18/07, Geoff Huston wrote:
I'll break up this response into a number of posts on each topic, if thats ok. On subject names: Steve said:The issuer of a cert has to verify that the requester of the cert properly represents the subject name in the cert. What I have argued it NOT that these names are not important, but rather that it IS important that hey NOT be human meaningful, and thus a random character string is desirable. The rationale here is that an issuer will incur liability for attesting to a human meaningful name in a cert; you will have to act like DNS registrars. So, to avoid that problem, and to make like easier (not just less litigious) for registries, I strongly recommend that the subject name for any cert NOT issued to an RIR or NIR be restricted to just one attribute (Common Name) and that the common name be a string of letters and numbers that are selected by the issuer with an intent to be non-meaningful! Whle we could apply the same criteria to RIRs and NIRs, there are so few of these, and their names are presumably not contentious (except maybe for Taiwan?), that it seems safe to use meaningful name here.I was working under a similar assumption in the context of the APNIC CA, and I was thinking that the APNIC CA CPS would include a note to the effect that certificates issued by APNIC would use a non-meaningful subject name for all certificates issued by APNIC, with the single exception of certificates issued to other RIRs.
OK.
The SubjectAltName has some options which I don;t have any particular preference for: a) omit SubjectAltName from all APNIC-issued certs, b) use the subject's suggested AltNmae, if provided in a Request and omit it otherwise or c) use the "OrgName" from the APNIC Resource Allocation database as the SubjectAltName in all cases and not use the name proposed in the request.
This sort of policy strikes me as likely to lead to trouble. First, you need to understand why anyone should have a SAN extension in a cert you issue. Second, ask if you want to accept the extra liability that will accrue from issuing a cert with a SAN. Third, even if you use a name in your database, you will accrue added liability, and create more opportunities for misuse of these certs.
I believe that this approach is consistent with the rescert draft. By placing in the CPS allows each issuer to determine what is appropriate for them under their circumstances. Of course it also implies that Relying Parties are positioned into a lowest common denominator mode, and, in general, cannot assume that the SubjectName or the SubjectAltName have any significance in any particular Resource Certificate in this PKI.
SInce we have a uniform CP for the PKI, I think it makes more sense to make a clear statement about this in the CP, rather than in each CPS. In our environment, the CPS serves more as a way to inform your Subjects about how to interact with you, rather than as a guide for the RPs. The CP is the way to inform all RPs about the common basis for use of certs.
So is an approach of: "It depends on the Issuer's CPS how the Issuer will determine the SubjectName and SubjectAltName of issued certificates" a reasonable one in the context of PKIs?
I'd rather not rely on that, for the reasons cited above. Steve
