> 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. The RFC does not even clearly state that the first
certificate in the bundle must be used in signing. 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.
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. I'm not saying this should be allowed, but without
additional restrictions in the RFC one must be prepared to deal with this
case.
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.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
