On Wed, Nov 5, 2014 at 8:26 AM, sulabh jain <sulabh....@gmail.com> wrote:
> The text below only says that the CERTREQ is a suggestion for a preffered > Certificate, which as well may be ignored and a different Certificate can > be presented in response. But it does not say that without receiving the > CERTREQ, a certificate should be sent back. > > RFC 4945 > > 3.2.6. Presence or Absence of Certificate Request Payloads > > When in-band exchange of certificate keying materials is desired, > implementations MUST inform the peer of this by sending at least one > CERTREQ. In other words, an implementation that does not send any > CERTREQs during an exchange SHOULD NOT expect to receive any CERT > payloads. > > Now, looking at this one would say an implementation will be non compliant > if it did not send a CERTREQ and expected a certificate in response. > > > Also the same RFC says: > > 3.3.6. Certificate Payloads Not Mandatory > An implementation that does not receive any CERTREQs during an > exchange SHOULD NOT send any CERT payloads, except when explicitly > configured to proactively send CERT payloads in order to interoperate > with *non-compliant* implementations that fail to send CERTREQs even > when certificates are desired. > > Now my question will be, an implementation that is not sending a CERTREQ > and expecting a certificate, will that be non compiant to the standards ? > As per above ? > > Regards > Sulabh > On Wed, Nov 5, 2014 at 2:18 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > >> 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 <sulabh....@gmail.com> 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 >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
