Paul Wouters writes:
> 5.1.3. X.509 Certificate Extensions
>
> Conforming IKE implementations MUST recognize extensions that must or
> may be marked critical according to this specification. These
> extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
>
> [...]
>
> With respect to
> compliance with the PKIX certificate profile, IKE implementations
> processing certificates MAY ignore the value of the criticality bit
> for extensions that are supported by that implementation, but MUST
> support the criticality bit for extensions that are not supported by
> that implementation. That is, a relying party SHOULD processes all
> the extensions it is aware of whether the bit is true or false -- the
> bit says what happens when a relying party cannot process an
> extension.
This is the important part for you.
I.e., critical bit DOES NOT affect the processing of the extension if
it is understood and is can be parsed. If implementation does not
understand some extension then critical bit is inspecteded, and if it
is TRUE the validation fails. If it is FALSE, then extension can
safely be ignored.
Or as rfc5280 puts it:
(o) Recognize and process any other critical extension present in
the certificate. Process any other recognized non-critical
extension present in the certificate that is relevant to path
processing.
If it marked as critical, you must recognize and process it. The
contents of the extension is then policy matter.
> So what should a crypto library do?
>
> - Ignore all EKU's in IPsec profile mode?
It can do that, as long as that is policy decicion that is done by the
code. I.e., if it understands what EKU is and has a policy that is
configured to allow all extended key usage values always, then from
outside it is just same as ignoring the whole EKU.
> - Ignore the critical flag in all EKU's in IPsec profile mode?
It can ignore the critical bit as long as it supports EKU. This means
if there is any code that understands how to parse EKU and compare it
against the configured policy, then it can ignore the critical bit.
What the policy is then defined to do, is complete outside the matter
of critical bit.
If it does not understand what EKU is then it can never find EKU that
has critical bit on, it will find unknown extension it does not know
about that has critical bit on, and then it needs to fail the
validation.
> - Consider serverAuth as "supported" or "unsupported" for the IPsec
> profile?
As I said in most cases IPsec profile for crypto library can just
parse the EKU and ignore the contents of it unless there is policy
that requires a way to differentiate for example TLS and IPsec
certificates.
I.e., the default configuration should be that any value of EKU or
missing EKU is ok for IPsec profile (i.e., effectively ignore it,
except than check that it is formatted correctly).
It may also be possible to configure the policy checks so that it does
require either id-kp-ipsecIKE or anyExtendedKeyUsage to be present
(and it might also require EKU to be present always, or assume
certificate is ok even if no EKU is present).
> - If "supported", should it ignore the critical flag in IPsec
> profile mode?
There is no supported or unsupported for values inside the EKU. If the
code knows how to parse extended key usage extension then the critical
bit does not matter. Critical bit DOES NOT affect for anything that is
inside the extension itself (unless it is something that it cannot
process, for example there is formatting error inside critical
extension, i.e., the contents of the extended key usage exteions is
not sequence of object ids).
> - Should it consider the above differently depending on id-kp-ipsecIKE
> or anyExtendedKeyUsage being present?
Depends on the policy.
> As for the last question, that is theoretical. This usage is simply
> not used in the wild and requiring it is not going to help anyone at
> this point.
But that is the policy decision code, not the actual certificate
parsing part, so that does not depend on the certificate processing
library, it depends on the required policy.
> Chairs: I think this is a topic worth discussing, because it might make
> sense to update 4945 to reflect the reality of dual use certificates
> that only have the serverAuth EKU.
I think the problem is mostly in the last
o Otherwise, reject cert.
as that is only needed if "certificate is intended to be used with
both IKE and other applications".
If certificate is only inteded to be used with IKE, then CAs SHOULD
NOT include EKU, but validation can also accept the certificate
regardless of the EKU contents.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
