[IPsec] #120: CA indication with cert req - allowed types

[Tero Kivinen <[e-mail]>]

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
> here?

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 3.2.7.2. 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
> removed. 

Most likely.
-- 
[e-mail]