|Main Archive Page > Month Archives > ipsec archives|
Yaron Sheffer writes:
> Sec. 3.7 has:
> The contents of the "Certification Authority" field are defined only
> for X.509 certificates, which are types 4, 10, 12, and 13. Other
> values SHOULD NOT be used until standards-track specifications that
> specify their use are published.
This is clearly wrong and is not present in the RFC4306. There is two meanings for the certificate request payload, one is to specify preferred format in which certificates are requested and another is to tell which authority the certificate is wanted from.
So if someone wants to have certificate payloads in raw rsa format, he should be able to give certificate request with encoding of type 11 and with empty authority field (as for raw rsa keys there is no authority field). Also as the certificate request is just hint the contents of the authority field is not that important, it is there just in case the other end happens to have MULTIPLE "certificates" it could use and needs to decide which of them to use. If it has only one of the requested format then it should send it regardless what the authority field said.
So the text most likely should say that "For other values the certificate authority field contents is not defined, and can be anything (or empty) until specifications that specify their contents is published."
> This excludes certificate requests of type 7, i.e. for CRLs. For
> requesting a specific CRL type 7 would make sense, in particular in
> chain situations. Should we add it to the list of allowed types
Giving certificate authorities for the CRLs is usually no operation as it will be the same as the ones for X.509 certificates (usually hosts do trust same CAs for certificates and CRLs, they do not have separate sets of authorities for those two uses).
So in most cases certificate request of type 7 is just indicating that other end would like to have CRLs inline also if possible in addition to certificates, and the authority field could be empty there.
This kind of telling only the format not the exact authority is inherited from the IKEv1 and is specified for example in the RFC4945 section 18.104.22.168. I think we had discussion about this when we were specifying IKEv2 as some people wanted to disallow it but I think we decided to allow it (at least I couldn't find text in the RFC4306 which would disallow it).
> OTOH, this allows type 10, which is unspecified and should be
Most likely. -- firstname.lastname@example.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec