CTI TAXII Subcommittee

All, Currently in the pre-draft document we have the following verbiage. This specification defines requirements for using HTTPS; this specification does not define requirements for using non-encrypted HTTP. All TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS.  Question: Do we need to add anything extra about specific types of HTTPS, TLS version, etc?   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Hi, Thanks for asking. Yes I think we should specify/highly recommend TLS My favorite resource:  https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ Cheers On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: All, Currently in the pre-draft document we have the following verbiage. This specification defines requirements for using HTTPS; this specification does not define requirements for using non-encrypted HTTP. All TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS.  Question: Do we need to add anything extra about specific types of HTTPS, TLS version, etc?   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

Please propose some updated verbiage... Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: Hi, Thanks for asking. Yes I think we should specify/highly recommend TLS My favorite resource:  https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ Cheers On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: All, Currently in the pre-draft document we have the following verbiage. This specification defines requirements for using HTTPS; this specification does not define requirements for using non-encrypted HTTP. All TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS.  Question: Do we need to add anything extra about specific types of HTTPS, TLS version, etc?   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret <bret.jordan@bluecoat.com>: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg." > > On Dec 15, 2015, at 11:35, Jerome Athias <athiasjerome@GMAIL.COM> wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret <bret.jordan@bluecoat.com> wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> >

I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS.  HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg." > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London,  WC2B 6NH Tel: 07973 123 038 official:  adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk

I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS.  HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg. > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 >> Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg. >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London,  WC2B 6NH Tel: 07973 123 038 official:  adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk Attachment: smime.p7s Description: S/MIME cryptographic signature

Just want to play devils advocate - one problem with having things like "MUST support TLS 1.2" in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger <Eric.Burger@georgetown.edu> To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org> Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: <cti-taxii@lists.oasis-open.org> I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me.
On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg." > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk

Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks. On Dec 16, 2015, at 9:59 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Just want to play devils advocate - one problem with having things like MUST support TLS 1.2 in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger < Eric.Burger@georgetown.edu > To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: < cti-taxii@lists.oasis-open.org > I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg. > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg. >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk Attachment: smime.p7s Description: S/MIME cryptographic signature

Regarding HTTPS – My hope is that we can find some language that is relevant both today and tomorrow. Of particular note, what specification could have anticipated the shift from SSL to TLS? A spec that required “the highest version of SSL available” would
be woefully behind today’s technology stack.


Thank you.
-Mark









From: < cti-taxii@lists.oasis-open.org >, Eric Burger < ewb25@georgetown.edu > on behalf of Eric Burger < Eric.Burger@georgetown.edu >
Date: Wednesday, December 16, 2015 at 11:09 AM
To: " cti-taxii@lists.oasis-open.org " < cti-taxii@lists.oasis-open.org >
Subject: Re: [cti-taxii] HTTPS





Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a
MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks.



On Dec 16, 2015, at 9:59 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote:



Just want to play devils advocate - one problem with having things like "MUST support TLS 1.2" in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating
that people implement an insecure protocol, until we revise the standard.


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif> Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so

From: Eric Burger < Eric.Burger@georgetown.edu >
To: " cti-taxii@lists.oasis-open.org " < cti-taxii@lists.oasis-open.org >
Date: 12/16/2015 10:55 AM
Subject: Re: [cti-taxii] HTTPS
Sent by: < cti-taxii@lists.oasis-open.org >





I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box.

One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc.
For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought
that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc.

I know, “send text.” I may get to it over the break if someone does not jump in before me.


On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk >
wrote:

I would advise specifying TLS v 1.2 or higher rather than 1.1.

There seems no reason not to go for v1.2.


On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote:

TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for
confidentiality, identification, and authentication, when sending
TAXII messages over HTTPS. HTTPS is specified in Section 2 of
[RFC2818].

NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt

2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >:
> Please propose some updated verbiage...
>
>
> Thanks,
>
> Bret
>
>
>
> Bret Jordan CISSP
> Director of Security Architecture and Standards Office of the CTO
> Blue Coat Systems
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
> not be unscrambled is an egg."
>
> On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote:
>
> Hi,
>
> Thanks for asking.
> Yes I think we should specify/highly recommend TLS
>
> My favorite resource:
> https://www.feistyduck.com/books/bulletproof-ssl-and-tls/
>
> Cheers
>
> On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote:
>>
>> All,
>>
>> Currently in the pre-draft document we have the following verbiage.
>>
>> This specification defines requirements for using HTTPS; this
>> specification does not define requirements for using non-encrypted HTTP. All
>> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS.
>>
>>
>> Question:
>> Do we need to add anything extra about specific types of HTTPS, TLS
>> version, etc?
>>
>>
>> Thanks,
>>
>> Bret
>>
>>
>>
>> Bret Jordan CISSP
>> Director of Security Architecture and Standards Office of the CTO
>> Blue Coat Systems
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
>> can not be unscrambled is an egg."
>>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




--
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B 6NH

Tel: 07973 123 038
official: adam.cooper@digital.cabinet-office.gov.uk
official sensitive: adam.cooper@govdigital.gsi.gov.uk

Precisely. The point is we do not have a crystal ball. Also, saying “highest version of SSL available” is not actionable and does not enable interoperability. It does not mean anything to anyone. MUST implement SSL 1.0 does all of that, and by now an errata that says MUST reject SSL 1.0 and MUST implement TLS 1.2 is sufficient to ensure security and interoperability. On Dec 16, 2015, at 11:21 AM, Mark Davidson < mdavidson@soltra.com > wrote: Regarding HTTPS – My hope is that we can find some language that is relevant both today and tomorrow. Of particular note, what specification could have anticipated the shift from SSL to TLS? A spec that required “the highest version of SSL available” would be woefully behind today’s technology stack. Thank you. -Mark From: < cti-taxii@lists.oasis-open.org >, Eric Burger < ewb25@georgetown.edu > on behalf of Eric Burger < Eric.Burger@georgetown.edu > Date: Wednesday, December 16, 2015 at 11:09 AM To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Subject: Re: [cti-taxii] HTTPS Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks. On Dec 16, 2015, at 9:59 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Just want to play devils advocate - one problem with having things like MUST support TLS 1.2 in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger < Eric.Burger@georgetown.edu > To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: < cti-taxii@lists.oasis-open.org > I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg. > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg. >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk Attachment: smime.p7s Description: S/MIME cryptographic signature

Mark and I have asked Eric to put together some official verbiage for the HTTPS stuff that we can use in the document. Once he has time to do that, we will send it to the list.  Look for something next week.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 16, 2015, at 09:24, Eric Burger < Eric.Burger@georgetown.edu > wrote: Precisely. The point is we do not have a crystal ball. Also, saying “highest version of SSL available” is not actionable and does not enable interoperability. It does not mean anything to anyone. MUST implement SSL 1.0 does all of that, and by now an errata that says MUST reject SSL 1.0 and MUST implement TLS 1.2 is sufficient to ensure security and interoperability. On Dec 16, 2015, at 11:21 AM, Mark Davidson < mdavidson@soltra.com > wrote: Regarding HTTPS – My hope is that we can find some language that is relevant both today and tomorrow. Of particular note, what specification could have anticipated the shift from SSL to TLS? A spec that required “the highest version of SSL available” would be woefully behind today’s technology stack. Thank you. -Mark From: < cti-taxii@lists.oasis-open.org >, Eric Burger < ewb25@georgetown.edu > on behalf of Eric Burger < Eric.Burger@georgetown.edu > Date: Wednesday, December 16, 2015 at 11:09 AM To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Subject: Re: [cti-taxii] HTTPS Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks. On Dec 16, 2015, at 9:59 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Just want to play devils advocate - one problem with having things like MUST support TLS 1.2 in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger < Eric.Burger@georgetown.edu > To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: < cti-taxii@lists.oasis-open.org > I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg. > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg. >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

The solution just hacked out (proposed, not accepted yet) in STIR is to have two documents. One describing the protocol, which points to another, that describes the MTI security features. That way one can change the security features (e.g., TLS 3.9 instead of TLS 1.2) without touching the base protocol document. Former document is tens of pages (describing TAXII). Later document is a few pages (mandatory security protocols and their respective interoperability instructions). On Dec 16, 2015, at 11:24 AM, Eric Burger < Eric.Burger@georgetown.edu > wrote: Precisely. The point is we do not have a crystal ball. Also, saying “highest version of SSL available” is not actionable and does not enable interoperability. It does not mean anything to anyone. MUST implement SSL 1.0 does all of that, and by now an errata that says MUST reject SSL 1.0 and MUST implement TLS 1.2 is sufficient to ensure security and interoperability. On Dec 16, 2015, at 11:21 AM, Mark Davidson < mdavidson@soltra.com > wrote: Regarding HTTPS – My hope is that we can find some language that is relevant both today and tomorrow. Of particular note, what specification could have anticipated the shift from SSL to TLS? A spec that required “the highest version of SSL available” would be woefully behind today’s technology stack. Thank you. -Mark From: < cti-taxii@lists.oasis-open.org >, Eric Burger < ewb25@georgetown.edu > on behalf of Eric Burger < Eric.Burger@georgetown.edu > Date: Wednesday, December 16, 2015 at 11:09 AM To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Subject: Re: [cti-taxii] HTTPS Brilliant minds think alike. I just had this very exchange on the STIR list, where I was the one saying what you said. The answer is that no matter what, once the hole in TLS 1.2 gets exposed, we will need to issue new guidance anyway. The point of having a MUST now is to establish the bottom baseline and set the least common denominator for downgrade attacks. On Dec 16, 2015, at 9:59 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Just want to play devils advocate - one problem with having things like MUST support TLS 1.2 in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger < Eric.Burger@georgetown.edu > To: cti-taxii@lists.oasis-open.org < cti-taxii@lists.oasis-open.org > Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: < cti-taxii@lists.oasis-open.org > I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg. > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg. >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk Attachment: smime.p7s Description: S/MIME cryptographic signature

Which is exactly why I said: "TLS 1.2 or higher". The standard sets the baseline not the limit.  I would also say that nothing should ever be expected to last forever. With that in mind we set the best available baseline now ie TLS 1.2.  On Wednesday, 16 December 2015, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: Just want to play devils advocate - one problem with having things like "MUST support TLS 1.2" in a standard vs. leaving it more open-ended, is what happens if/when TLS 1.2 has a gaping hole discovered in 6 months... we now have a standard mandating that people implement an insecure protocol, until we revise the standard. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Eric Burger ---12/16/2015 10:55:52 AM---I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so From: Eric Burger < Eric.Burger@georgetown.edu > To: " cti-taxii@lists.oasis-open.org " < cti-taxii@lists.oasis-open.org > Date: 12/16/2015 10:55 AM Subject: Re: [cti-taxii] HTTPS Sent by: < cti-taxii@lists.oasis-open.org > I strongly support mandating TLS 1.2. It is supported by all the open source servers and clients, so there is lots of code to reuse, steal, or just run out-of-the-box. One word of warning: specifying HTTPS requires a bit more work than just saying “MUST implement TLS 1.2.” We need to specify what servers and clients should expect in the Subject field, any limitations or MTI’s for cypher suites, etc. For example, for the open server TAXII case, I would say we would still require HTTPS, but allow the NULL cypher suite. That gets us some level of client and identity, as well as GZIP for free (well, paid for). That will also eliminate the mistaken thought that we need to allow HTTP access for open servers. Other things to specify is either requirements or implementation suggestions for what to do with self-signed certificates, etc. I know, “send text.” I may get to it over the break if someone does not jump in before me. On Dec 16, 2015, at 5:48 AM, Adam Cooper < adam.cooper@digital.cabinet-office.gov.uk > wrote: I would advise specifying TLS v 1.2 or higher rather than 1.1. There seems no reason not to go for v1.2. On 16 December 2015 at 10:24, Jerome Athias < athiasjerome@gmail.com > wrote: TAXII systems MUST use TLS version 1.1 [RFC4346] or higher for confidentiality, identification, and authentication, when sending TAXII messages over HTTPS. HTTPS is specified in Section 2 of [RFC2818]. NB: stolen from https://www.rfc-editor.org/rfc/rfc6546.txt 2015-12-15 21:40 GMT+03:00 Jordan, Bret < bret.jordan@bluecoat.com >: > Please propose some updated verbiage... > > > Thanks, > > Bret > > > > Bret Jordan CISSP > Director of Security Architecture and Standards Office of the CTO > Blue Coat Systems > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg." > > On Dec 15, 2015, at 11:35, Jerome Athias < athiasjerome@GMAIL.COM > wrote: > > Hi, > > Thanks for asking. > Yes I think we should specify/highly recommend TLS > > My favorite resource: > https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ > > Cheers > > On Tuesday, 15 December 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: >> >> All, >> >> Currently in the pre-draft document we have the following verbiage. >> >> This specification defines requirements for using HTTPS; this >> specification does not define requirements for using non-encrypted HTTP. All >> TAXII compliant communications and interactions in TAXII 2 MUST use HTTPS. >> >> >> Question: >> Do we need to add anything extra about specific types of HTTPS, TLS >> version, etc? >> >> >> Thanks, >> >> Bret >> >> >> >> Bret Jordan CISSP >> Director of Security Architecture and Standards Office of the CTO >> Blue Coat Systems >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that >> can not be unscrambled is an egg." >> > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London, WC2B 6NH Tel: 07973 123 038 official: adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk -- Adam Cooper Identity Assurance Programme Government Digital Service 125 Kingsway, London,  WC2B 6NH Tel: 07973 123 038 official:  adam.cooper@digital.cabinet-office.gov.uk official sensitive: adam.cooper@govdigital.gsi.gov.uk