The SenderCertificate now allows an entire chain.

The stacks need to be updated.

RC 1.02.10

From telecon minutes:

Mantis Issue 1999 – text was excepted, but thought Liam and/or Matthias should also review before closing

Re-opened at Liam's request. He will add a note.

Randy and I discussed this and in particular discussed the additional variability this would add to the existing security policies, Basic128RSA15 and Basic256. We feel that given the MessageChunk parameter in UA TCP is a variable, adding support for certificate chains to these existing policies will make it very difficult for end users to produce certificate chains that will work in every circumstance without much testing and trial and error.

It is proposed to allow certificate chains in the SenderCertificate (as drafted in part 6, 1.02.10) subject to inclusion in specific security policies. This means that any new security policies that are added can mandate support for chains but that the existing Basic128RSA15 and Basic256 profiles will not allow them.

It is proposed to amend part 6 to specify that chains are only supported where explicitly stated in a part 7 security policy.

This is a feature that we need and discussed already a few years ago.

The only problem we may run into is that the certificate can not be chunked when creating a secure channel and our minimum message size is 8KB. This may be a problem for longer certificate chains.

We discussed in Foxboro that 8K is enough for chains that are 2-4 deep.

The spec clearly lays out a formula for calculating the maximum size the SenderCertficate including any chains.

The text now indicates that the support for chains depends on the profile.

Resolved in RC 1.02.12

During the UA telecon 2012-05-15 we reviewed Randy's changes to 0001999 based on Liam's input. The change was to limit the use of certificate chains to the new security profiles with key lengths greater than 2048 bits. But the certificate field is already limited in size whether it contains a single cert or a chain so it seems unnecessary to limit chains to only the new profiles. This will need further review in a meeting with more participants.

Discussed in telecon 2012-05-29 and decided that: Servers and Clients know the other party's respective MaxMessageSize at the time the certificates are exchanged so the requirement shall be that the sender will truncate the certificate chain at a certificate boundary such that the MaxMessageSize of the receiver is not violated.

Updated text to always allow chains but specifically require that senders honour the negotiated MaxSenderMessageSize.

Change in RC 1.02.13

Reviewed and agreed to changes is 2012-06-26 telecon.