It’s possible, but then why not send it? The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of-band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator).
> On Nov 5, 2014, at 6:52 AM, sulabh jain <[email protected]> wrote: > > Hi Ipsec experts, > > RFC 5996 section 3.7 > 3.7 <https://tools.ietf.org/html/rfc5996#section-3.7>. Certificate Request > Payload > > > > The Certificate Request payload, denoted CERTREQ in this document, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when the > sender needs to get the certificate of the receiver. > > Does that leave a scope for the following use case: > > The sender does not send a cert request payload, but still expects a > certificate in the Auth Response. > > > Regards > Sulabh > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
