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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 30 Oct 2009 01:14:56 +0200

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

OTOH, this allows type 10, which is unspecified and should be removed.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Oct 2009 16:33:04 +0200

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

Most likely.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Fri, 30 Oct 2009 17:56:15 -0400

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

RFC 4945 states that implementations SHOULD NOT send CERTREQs for types 7
and 8.  If they are sent then an implementation MUST NOT require the
recipient to respond and the recipient MAY ignore the request.  Given that
I don't expect that it is common that implementations send CERTREQs with
type 7 or 8 to begin with.  If they do I agree with Tero that an empty
certificate authority field is probably sufficient.

OTOH, I would not be opposed to adding RFC 4945's "SHOULD NOT send CERTREQs
for type 7 and 8" statement here.

> OTOH, this allows type 10, which is unspecified and should be removed.

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: David Wierbowski <[email-masked]>
Date: Fri, 30 Oct 2009 18:30:42 -0400

> anything (or empty) until specifications that specify their contents
I do not think they can be anything.  I think they need to be empty until
specifications that specify their contents are published.

Dave Wierbowski

 Phone:
    Tie line:   620-4055
    External:  607-429-4055