David Wierbowski writes:
>
> > Tero said:
> >
> > 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).
>
> Tero, I do not agree that it is more clear that only one CERT payload would
> be sent in the X.509 bundle case. I agree logically that makes sense, but
> the RFC does not mandate that. In fact the RFC is very vague in the case
> of the X.509 bundle.
I think it is quite obvious that you are not supposed to use multiple
hash and url of X.509 bundle payloads, even when it is not
specifically forbidden.
> The RFC does not even clearly state that the first certificate in
> the bundle must be used in signing.
That is not true. The 1.2 clearly says:
... If any CERT
payloads are included, the first certificate provided MUST contain
the public key used to verify the AUTH field.
Which uses words "first certificate provided", and does not talk about
first CERT payload just because of this.
Again this same thing is reiterated in the 3.6:
... 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.
Again it talks about "first certificate", not first CERT payload.
Note that term "certificate" there is defined so it can be also other
things than certificates, as it said at the beginnig of 3.6:
... Note that the
term "Certificate Payload" is somewhat misleading, because not all
authentication mechanisms use certificates and data other than
certificates may be passed in this payload.
> An x509 bundle is
> simply a sequence of CertificateOrCRL. It does not impose any order of the
> certificates in the bundle, it does not impose any relationship on the
> certificates in a bundle, it does not even require certificates to be
> within the bundle (i.e. the bundle could just contain a CRL), and it does
> not limit the number of CERT payloads that can be sent.
Otherwise true, but IKE do require the first certificate that
responder sees when going through the CERT payloads and going through
contents of the CERT payloads and going through the URLs the CERT
payload contents might have pointed him to, MUST contain the public
key used to sign the AUTH payload.
That specific MUST is not limited to multiple CERT payloads. It is
MUST specified in 2 different locations and in both cases it talks
about "certificate provided" or just "first certificate".
> For example assume there was a cert chain CA1->CA2->EE. An implementation
> could decide to use encoding 4 to send the certificate of EE1, to use
> encoding 13 to send a URL of a bundle that contains the certificate of CA2
> and a CRL issued by CA2, and to use encoding 13 to send a URL of a bundle
> that contains a CRL issued by CA1. This would be valid according to what
> the RFC states.
Yes that is valid as long as the EE1 is the first certificate which is
provided to the recipient. If we take strict interpretation of the 3.6
where also CRLs are in this sense refered as "certificates", there
cannot even be any CRLs before the EE1.
I.e. the first CERT payload MUST either have EE1 as first certificate,
or the URL pointed by it MUST have EE1 as first certificate.
> I'm not saying this should be allowed, but without additional
> restrictions in the RFC one must be prepared to deal with this case.
Yes, your case is allowed, and actually might be efficient way of
doing things, as CA1 and CA2 CRLs might be quite different in size and
might have different update frequencies, thus one of the bundles might
be very static (and large) and another might be updated very often
(but is small).
> I'm not opposed to adding text that says:
>
> When X.509 bundle is used only one certificate payload MUST be sent .
> The first certificate in an X.509 bundle MUST be the certificate used
> when creating the signature contained in the AUTH payload. Other
> certificates and CRLs in the X.509 bundle SHOULD relate to the CA trust
> chain and may appear in only order.
>
> I think this would simplify processing and not be too restrictive.
This would add new MUST (1st one), and reiterate old MUST (2nd one),
and add new SHOULD (3rd one).
I do not think we want to add such text now (I do not see need for it,
and I think it will be too restrictive).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
