Yoav Nir writes:
> I've submitted issue #107 about certificate encoding.
>
> IMO it's not clear how certificate chains are to be encoded in IKEv2.
>
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
If certificate chain is sent using X.509 certificate - signature (4)
format, then it is sent as multiple separate CERT payloads.
There is text about this in multiple places in the RFC4306. In 1.2 it
clearly indicates that there can be multiple CERT payloads and the
first certificate provided must contain the public key used to verify
AUTH field:
----------------------------------------------------------------------
1.2. The Initial Exchanges
...
2.15). It might also send its certificate(s) in CERT payload(s) and
a list of its trust anchors in CERTREQ payload(s). If any CERT
payloads are included, the first certificate provided MUST contain
the public key used to verify the AUTH field. The optional payload
...
----------------------------------------------------------------------
and then there is the text you put to the #107:
----------------------------------------------------------------------
3.6. Certificate Payload
...
X.509 Certificate - Signature (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload.
...
Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
first two Hash and URL formats (with HTTP URLs). Implementations
SHOULD be capable of being configured to send and accept Raw RSA
keys. If multiple certificates are sent, the first certificate MUST
contain the public key used to sign the AUTH payload. The other
certificates may be sent in any order.
...
----------------------------------------------------------------------
So if that format 4 (and 7) is used then multiple CERT payloads are
used and first of the CERT payloads must be the one matching the
public key of the AUTH payload.
If other formats which support bundles are used (RCKS#7 wrapped (1),
hash and url of X.509 bundle (13)) are used then there usually is only
one payload containining the whole chain. As the current document
leaves PCKS#7 wrapped X.509 certificates with very little
specification implementations could also do things differently there
(i.e. wrap each certificate separately or do something else).
For the X.509 bundle I think the format is more clear and only one
CERT payload is sent containing hash and url of all certificates and
crls needed (and first certificate there is the one used for AUTH
payload).
It might be good to add bit more text to the X.509 Certificate -
Signature (4) text, i.e something like: "If multiple certificates are
sent, then each of them is encoded as separate CERT payload.".
Note, that some implementations might send certificates in multiple
formats, i.e. they might send RAW RSA key first, than then provide for
example HASH and URL of X.509 bundle also. Depending on the recipient
it might jsut use the RAW RSA key or might might actually fetch the
bundle and use that.
Note, that the ordering requirement that first certificate provided
MUST contain the public key used to verify AUTH field, is for the
first certificate provided, it is not separately for each certificate
encoding type, i.e. if first "certificate" provided happened to be in
RAW RSA format, then even if the same public key is given out in
different format too (for example as X.509 cetificate), there is no
ordering requirements there anymore. Of course it would be best if
implementations would keep the same order there, i.e. if they include
same public key used in AUTH payload in multiple formats they always
include that first for each certificate type they provide (i.e. the
first X.509 certificate - signature (4) CERT payload has the public
key used in AUTH payload, even when it is not strictly required if
there has already been other CERT payloads before it in different
format).
Smart implementations will simply put all certificates regardless of
format to their "certificate validator", and then take public key from
the first CERT payload (most likely ignoring all they do not
understand) and try to verify if that public key can be verified to be
valid with configured trust anchors.
I do not expect mixing of cert encodings to happen that much, but the
RAW RSA key combined with X.509 certificates might be the exception of
that. I.e. in some environments it might be useful to provide both, so
minimal implementations just use preconfigured RAW RSA key, and other
implementations might actually verify the certificates instead.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
