>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.
>
I agree that text like this should be added. I suggest some minor
editorial changes (change "In case those formats" to "When" and
"are" to "is":
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). When formats
which contain one certificate are used and multiple certificates
are to be sent then each certificate is sent as separate
Certificate Payload.
In that past I've asked if the first certificate payload is encoded
using type 13 does the first certificate in the bundle have to be
the one used to create the signature and you've answered yes. Perhaps
we should also clarify that here. I do not think we can make such
a statement when type 1 is used. I know of at least one vendor that
uses type 1. The signing cert is not the first certificate in their
PKCS #7 data.
>
>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."
I prefer your previous wording.
>
>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.
>
I agree that we should state that mixing multiple types of
certificate payloads is allowed. The examples are helpful,
but I'm not sure we need to include them in the text.
>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.
I agree that we should stste the extra certificate payloads are there to
help validation of the first certificate, not necessarely to form a single
chain.
>--
>kivi...@iki.fi_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
