Sharon, Brian, Sorry that I haven't responded to this sooner. I thought that we had made changes to the text in section 8.1.5, but could not find any evidence of it until yesterday. New text for section 8.1.5, which covers the case that we have been discussing, appears in the Proposed Draft Amendment (PDAM) to X.509. The PDAM would normally be available for download from an FTP site, but that site seems to be down for the moment. So, I have extracted the section of the PDAM that describes the proposed changes to section 8.1.5 and have attached the result. Note that this text is not yet part of the standard, but since everyone seems to agree with the changes, I expect that the changes will be approved at some point. Dave Sharon Boeyen wrote: >From what I can remember, I believe it was just a simple error that we worded >b) the way we did. We thought about the timestamp situation (probably because >that was a hot topic on PKIX at the time), but didn't think about the split >for CRL signing. I think its as simple as that, but I would also like to hear >from others who were also involved in that discussion. Dave, your memory is >usually excellent - do you remember anything more than that regarding this >text? > >Sharon > >-----Original Message----- >From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] >Sent: Thursday, June 19, 2003 5:11 PM >To: Multiple recipients of list >Subject: Re: Test case 4.5.7 > > > >Sharon, > >The value of a CA to delegate CRL issuance to another private key, as is here >described, does make sense, and I do not see why X509 limits this case. I agree >with you that a DR should be raised, but am still interested in hearing if >others have anything to say in this regards, especially if one knows the >reasoning behind the original X509 text. > >Regards, >Brian > > > >>I agree that the test case is slightly different than the example I gave, but I >>think the general issue is more interesting in the type of scenario I gave as an >>example (at least from a business standpoint). In the test scenario, from a business >>standpoint, one could achieve the same result by issuing two separate self signed >>certificates (basically 2 trust anchors or roots) one for each key. But in the >>example I gave there would be a major impact on the paths so that's one I find >>more interesting from the standpoint of justifying the self-issued certificates, where >>one is to certify the crl signing key usage. If there is agreement that this is >>a reasonable requirement and the DR should be raised to modify 509, then I see >>the NIST test as just a special case of that. >> >>Do you agree that a DR should be raised against 509? >> >>Sharon >> >>-----Original Message----- >>From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] >>Sent: Wednesday, June 18, 2003 12:27 PM >>To: Multiple recipients of list >>Subject: Re: Test case 4.5.7 >> >>Thanks for your response Sharon. >> >>I wanted to point out that in this test case, the CA isn't really splitting its >>keyUsage per se, it is more creating a new one. Using your CA names (but >>applying the test case keyUsages), >> CA2.keyUsage=keyCertSign and >> CA2-selfIssued.keyUsage=cRLSign >>I believe this is what you meant in general, since a certificate with >>keyUsage=keyCertSign can issue certificates with any keyUsage. >> >>I have a related question, which I will move to the PKIX group, of whether >>self-issued certificates need to have their revocation status checked, in >>particular, when it signs the needed CRL as in this case. >> >>Regards, >>Brian >> >>Sharon Boeyen wrote: >> >> >>>As one of the folks who helped write that text in 509, I don't believe its >>> >>> >>>intent was to rule out the ability of a CA to roll over its keys and in so >>> >>> >>>doing split to use one key for signing certs and a different key for signing CRLs. >>>This test describes a special case of that where there aren't any other intermediates, >>>but the idea is the same - a decision to start using separate keys for these purposes. >>>(Although I agree that the current 509 text reads doesn't mention this as a reason >>>for issuing self issued certificates). >>> >>>For example, if CA 1 issued a cert to CA 2 and that cert has both keyCertSign >>>and cRLSign bits set in keyUsage and then CA 2 rolls its keys using a single self >>>issued cert that also includes both keyUsage bits set - this is fine. From a trust >>>standpoint this is really no different than if CA 2, when rolling its keys, issued >>>2 self issued certs, one with keyCertSign set and the other with cRLSign set. If this >>>wasn't allowed, then the only way CA 2 could split its keyUsage would be to have separate >>>certs issued at all stages of all possible paths from all trust anchors that relate to paths >>>that would include CA 2. I don't believe we intended that in the 509 text. >>> >>> >>>Rather in 509, I suspect we just didn't address the situation where a CA uses separate keys >>>for cert and CRL signing. Perhaps a Defect Report should be raised to address this properly >>>in 509. >>> >>>Dave? Others? >>> >>>-----Original Message----- >>>From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] >>>Sent: Wednesday, June 18, 2003 4:09 AM >>>To: Multiple recipients of list >>>Subject: Test case 4.5.7 >>> >>>Hi Dave, >>> >>>I've been looking at this test case, and it appears to me that it is illegal >>> >>> >>>according to X509. Perhaps you, or someone else, could lend some insight. >>> >>> >>>Let me first give some terminology: >>>CA1 = Basic Self-Issued CRL Signing Key CA Cert >>>CRLIssuer = Basic Self-Issued CRL Signing Key CRL Cert >>>(where CRLIssuer is a self-issued CA cert from CA1) >>> >>>The problem that I see is that CA1 issued CRLIssuer since X509 8.1.5 >>>describes >>>the only time self-issued certs may be issued (and the above case is not >>>allowed): >>> >>> There are three circumstances under which a certification authority may >>>issue >>> a certificate to itself: >>> a) as a convenient way of encoding its public key for communication to, >>> >>> >>> and storage by, its certificate users; >>> b) for certifying key usages other than certificate and CRL signing >>> (such as time-stamping); and >>> c) for replacing its own expired certificates. >>> >>>And b specifically rules out a self-issued CRLSigning certificate. >>> >>>Brian >>>
PDAM Enhancements to X.509.pdf