All of which taken together indicates the Sec. 3.6 needs to be rewritten. It'll be hard enough to get interoperability with all these options, but certainly if much remains undocumented.
We might even need to resort to defining what the mythical "minimal
implementation" is allowed to do.
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Thursday, August 27, 2009 9:57
> To: David Wierbowski
> Cc: ipsec@ietf.org; ipsec-boun...@ietf.org; Yaron Sheffer
> Subject: Re: [IPsec] #107: Sending certificate chains in IKEv2
>
> David Wierbowski writes:
> > I agree with Tero that Yoav's proposed text adds clarity and effectively
> it
> > does not add a new MUST; however, to address Paul's concern can we just
> > change the words "MUST be" to the word "are" or lower case "should be?"
> > For example:
> >
> > o X.509 Certificate - Signature (4) contains a DER encoded X.509
> > certificate whose public key is used to validate the sender's AUTH
> > payload. Note that with this encoding if a chain of certificates
> > needs to be sent, multiple CERT payloads are used, only the
> > first of which holds the public key used to validate the sender's
> > AUTH payload.
>
> This text looks good for me. And I think it is important to add this
> to X.509 Certificate - Signature (4) case, even when we have some
> generic text elsewhere saying same thing, as this is the most common
> case people are using now.
>
> > As Tero points out, this is the only way to send a chain this using
> X.509
> > Certificate - Signature.encoding. MUST terminology really is not needed
> in
> > my opinion.
>
> Agreed.
>
> I think in addition to that text we might want to add some generic
> text to the final paragraph saying:
>
> Some of the certificate formats can only contain one certificate
> (for example formats 4, 7, 11 and 12), and some can contain
> multiple certificates (for example 1, 13). In case those formats
> which contain one certificate are used and multiple certificates
> are to be sent then each certificate are sent as separate
> Certificate Payload.
>
> Or add similar text than what is in the 3.7 Certificate Request
> Payload which have following sentence at the end of first paragraph
> "If multiple CAs are trusted and the certificate encoding does not
> allow a list, then multiple Certificate Request payloads would need to
> be transmitted."
>
> One more thing, do we want to explictly mention that it is very common
> to mix multiple types of certificate payloads, i.e. send certificate
> multiple payloads some having X.509 Certificate - Signature (4) format
> and some having Certificate Revocation List (7) format.
>
> Another combination could be Raw RSA Key (11) and X.509 Certificate -
> Signature (4). In that case the Raw RSA Key (11) format is meant for
> minimal implementations who have the raw RSA key of the other end
> statically configured to their policy, and the X.509 Certificate -
> Signature (4) format is meant for full implementations which can
> process and validate certificates.
>
> Note also that not all certificates are there to form a chain, they
> can also provide other things like CRLs or even multiple different
> chains towards the different CAs (in case the private/public key use
> has certificates from multiple CAs, and other end didn't indicate any
> known CA), so the extra certificate payloads (after the first one used
> to sign the AUTH payload) are there just to help validation of the
> first certificate, not necessarely to form a chain.
> --
> kivi...@iki.fi
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
