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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
