Subject: Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 4 Nov 2021 18:04:02 +0000

Roman

I aligned with Mike, John, and Hans. 
Please see our feedback on your comments regarding Section 7 and Section 9 below.

> Von: Spasm <[email-masked]> Im Auftrag von Roman Danyliw
> Gesendet: Dienstag, 26. Oktober 2021 23:49
> 
> Hi!
> 
> I did an AD review of draft-ietf-lamps-cmp-algorithms-07 with my comments
> below.  Thanks for this work to evolve CMP.
> 
> ** Section 7.  I would have benefit from a bit more clarity on the direction
> provided in this section.
> 
> -- "The following criteria will help implementers choose appropriate algorithms
> for managing certificates"
> 
> The bulleted list seems like only part of the criteria.  As a non-exhaustive list,
> additional considerations might be the capabilities of the end-point (e.g., does
> the target deployment have hardware acceleration for some, are some
> algorithms simply out of reach due to available compute or expected software
> support); or perhaps local policy or compliance requirements?
> 
> -- "The cryptographic strength of the algorithm with the lowest security."
> 
> It seems like some words are missing here.  Is the intent here to guide the
> selection towards the algorithm that provides the minimum amount of strength
> relative to the needed security requirements?

Thank you for this feedback. We propose the following changes.
In addition to that we think another table in the introduction of Section 7 listing the different algorithms sorted by its security level (bits of security) would help. We plan to present such a table during the LAMPS session for further discussion.

Old:
   The following criteria will help implementers choose appropriate
   algorithms for managing certificates:

   *  The cryptographic strength of the algorithm with the lowest
      security.

      Note: To avoid consuming too much computational resources it is
      recommended to choose a set of algorithms offering roughly the
      same level of security.

   *  The entropy of the shared secret information or password when MAC-
      based message protection is used, e.g., MSG_MAC_ALG.

   Finally, the cryptographic strength of the system SHOULD be at least
   as strong as the algorithms and keys used for the certificate being
   managed.

New:
The overall cryptographic strength of a CMP deployment will depend on
several factors, including:
 
* Algorithm profile: The overall strength of the profile will be the strength
   of the weakest algorithm it contains.
 
* Message protection: The overall strength of the CMC message protection 
   - MAC-based protection: The entropy of the shared secret information or
     password when MAC-based message protection is used, e.g.,
     MSG_MAC_ALG.
   - Signature-based protection: The strength of the key pair and signature
     algorithm when signature-based protection is used, e.g., MSG_SIG_ALG
 
* Certificates managed: Finally, the cryptographic strength of the system
   SHOULD be at least as strong as the algorithms and keys used for the
   certificate being managed.
 
To avoid consuming too much computational resources it is
recommended to choose a set of algorithms offering roughly the
same level of security. Below are provided several algorithm profiles 
which are balanced, assuming the implementor chooses MAC secrets 
and / or certificate profiles of at least equivalent strength.

> 
> ** Section 7.1.  The text in this section seems it should explicit say that it is
> updating RFC4210.
> 
> OLD
> The following table contains definitions of algorithms used within
> 
> NEW
> The following table updates the definitions of algorithms used within

I am fine with this change.

> 
> ** Section 7.1.  If an algorithm is listed in the "Change from 4210" column,
> should it be considered the equivalent of being added to the "other" column (per
> Appendix D.2 of RFC4210?  If so, please be explicit about that.

We will delete the column "Changes from 4210" and introduced two columns, "Optional" and "Deprecated". "Deprecated" contains all algorithms define in RFC 4210 Appendix D.2 which SHOLUD NOT be used any more.

> 
> ** Section 7.1.  Table 1.
> 
> -- What does it mean for PasswordBasedMac to be in both the Mandatory and
> Change-from-4210 column for the MSG_MAC_ALG row?  It was already the MTI
> in RFC4210.  Same question and situation with D-H for the PROT_ENC_ALG row.

PBMAC1 became MANDATORY and PasswordBasedMac became OPTIONAL.

> 
> -- Should 3-DES be considered "other" in MSG_MAC_ALG and PROT_SYM_ALG?

3-DES (3-key-EDE, CBC mode) became Deprecated as you proposed below.

> 
> -- Editorial.  In PROT_SYM_ALG and SYM_PENC_ALG, the "3-DES (3-key-EDE),
> CBC Mode" should read "3-DES (3-key-EDE, CBC mode)" per the text in RFC4210.

Thanks for the clarification, we can fix this.

This is the Update we propose for Section 7.1
Old
   Change from 4210: Shows the changes in the Mandatory and Other
   algorithms from RFC 4210 [RFC4210].  These are included for backwards
   compatibility considerations.

   +============+===============+==================+===================+
   |Name        |Use            | Mandatory        |Change from 4210   |
   +============+===============+==================+===================+
   |MSG_SIG_ALG |protection of  | RSA              |DSA/SHA1           |
   |            |PKI messages   |                  |Others: RSA/MD5,   |
   |            |using signature|                  |ECDSA              |
   +------------+---------------+------------------+-------------------+
   |MSG_MAC_ALG |protection of  | PasswordBasedMac |PasswordBasedMac   |
   |            |PKI messages   | (RECOMMENDED:    |Others: HMAC, X9.9 |
   |            |using MACing   | PBMAC1)          |                   |
   +------------+---------------+------------------+-------------------+
   |SYM_PENC_ALG|symmetric      | AES-wrap         |3-DES(3-key-EDE),  |
   |            |encryption of  |                  |CBC Mode           |
   |            |an end entity's|                  |Others: AES, RC5,  |
   |            |private key    |                  |CAST-128           |
   |            |where symmetric|                  |                   |
   |            |key is         |                  |                   |
   |            |distributed    |                  |                   |
   |            |out-of-band    |                  |                   |
   +------------+---------------+------------------+-------------------+
   |PROT_ENC_ALG|asymmetric     | D-H              |D-H                |
   |            |algorithm used |                  |Others: RSA, ECDH  |
   |            |for encryption |                  |                   |
   |            |of (symmetric  |                  |                   |
   |            |keys for       |                  |                   |
   |            |encryption of) |                  |                   |
   |            |private keys   |                  |                   |
   |            |transported in |                  |                   |
   |            |PKIMessages    |                  |                   |
   +------------+---------------+------------------+-------------------+
   |PROT_SYM_ALG|symmetric      | AES-CBC          |3-DES(3-key-EDE),  |
   |            |encryption     |                  |CBC Mode           |
   |            |algorithm used |                  |Others: AES, RC5,  |
   |            |for encryption |                  |CAST-128           |
   |            |of private key |                  |                   |
   |            |bits (a key of |                  |                   |
   |            |this type is   |                  |                   |
   |            |encrypted using|                  |                   |
   |            |PROT_ENC_ALG)  |                  |                   |
   +------------+---------------+------------------+-------------------+

New
Optional: Algorithms which are OPTIONAL to support

Deprecated: Algorithms from RFC 4210 [RFC4210] which SHOULD NOT be used anymore

+============+===============+==========+=================+=============+
|Name        |Use            |Mandatory |Optional       |Deprecated   |
+============+===============+==========+=================+=============+
|MSG_SIG_ALG |protection of  |RSA       |ECDSA, EdDSA     |combinations |
|            |PKI messages   |          |                 |with MD5 and   |
|            |using signature|          |                 |SHA1         |
+------------+---------------+----------+-----------------+-------------+
|MSG_MAC_ALG |protection of  |PBMAC1    |PasswordBasedMac,|             |
|            |PKI messages   |          |HMAC, X9.9       |             |
|            |using MACing   |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|SYM_PENC_ALG|symmetric      |AES-wrap  |                 |3-DES        |
|            |encryption of  |          |                 |(3-key-EDE,  |
|            |an end entity's|          |                 |CBC Mode),   |
|            |private key    |          |                 |CAST-128, RC5|
|            |where symmetric|          |                 |             |
|            |key is         |          |                 |             |
|            |distributed    |          |                 |             |
|            |out-of-band    |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|PROT_ENC_ALG|asymmetric     |D-H       |ECDH, RSA        |             |
|            |algorithm used |          |                 |             |
|            |for encryption |          |                 |             |
|            |of (symmetric  |          |                 |             |
|            |keys for       |          |                 |             |
|            |encryption of) |          |                 |             |
|            |private keys   |          |                 |             |
|            |transported in |          |                 |             |
|            |PKIMessages    |          |                 |             |
+------------+---------------+----------+-----------------+-------------+
|PROT_SYM_ALG|symmetric      |AES-CBC   |                 |3-DES        |
|            |encryption     |          |                 |(3-key-EDE,  |
|            |algorithm used |          |                 |CBC Mode),   |
|            |for encryption |          |                 |CAST-128, RC5|
|            |of private key |          |                 |             |
|            |bits (a key of |          |                 |             |
|            |this type is   |          |                 |             |
|            |encrypted using|          |                 |             |
|            |PROT_ENC_ALG)  |          |                 |             |
+------------+---------------+----------+-----------------+-------------+

Currently we propose a mandatory algorithm use profile with 112bit strength. As recommendations are going from RSA2048 to RSA3072 we discussed, if it is better to make a profile mandatory offering 128 bit strength. 
Currently we also mandate to use AES256 for key-wrap and encryption for delivering centrally generated RSA2048 keys pairs. The encryption is stronger than delivered key pair. Should we mandate AES128 only?
Currently HMAC and X9.9 are listed as OPTIONAL for MSG_MAC_ALG as they were listed in RFC 4210 D.2. We propose to remove x9.9 and keep HMAC. Regarding use of HMAC we would propose adding a Security Consideration as follows.

   Symmetric key-based MAC algorithms as described in Section 6.2  MAY be 
   used as MSG_MAC_ALG.  The implementor MUST choose a suitable PRF 
   and ensure that the key  has sufficient entropy to match the overall security 
   level of the algorithm  profile. These considerations are outside the scope 
   of the profile.

@Russ and Roman, what is your opinion?

> 
> ** Section 9.  Can a reference be added for the theoretical weakness in
> PasswordBasedMac?

We are not aware of any clear description of PasswordBasedMac weakness. Therefor we propose the following change:

Old
   When using MAC-based message protection the use of PBMAC1 is
   preferable to that of PasswordBasedMac: first, PBMAC1 is a well-known
   scrutinized algorithm, which is not true for PasswordBasedMac and
   second, there exists a theoretical weakness in PasswordBasedMac,
   where the generated MAC key can be easily distinguished from a random
   key.

New
When using MAC-based message protection the use of PBMAC1 is preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known scrutinized algorithm, which is not true for PasswordBasedMac. Second, the PasswordBasedMac algorithm as specified in RFC 4211 section 4.4 is essentially PBKDF1 (as defined in RFC 2898 section 5.1) with an HMAC step at the end. Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in RFC 8018. PBKDF2 is superior to PBKDF1 in an improved internal construct for iterated hashing, and in removing PBKDF1's limitation of only being able to derive keys up to the size of the underlying hash function. Additionally, PBKDF1 is not recommended for new applications as stated in Section 5 of RFC 8018 and no longer an approved algorithm by most standards bodies, and therefore presents difficulties to implementors who are submitting their CMP implementations for certification, hence moving to a PBKDF2-based mechanism. This change is in alignment with RFC 9045 which updates RFC 4211 to allow the use of PBMAC1 in CRMF.

> 
> ** Section 9.  Editorially, the first paragraph ("RFC 4210 Appendix D.2 ...) and the
> two paragraphs of "In Section 7 ..." and "To keep the list ...", seem to be saying
> the same thing.  Recommend a merge.
> 

Okay, maybe we just remove the paragraph "To keep the list of algorithms"

> ** Section 9.
> In such systems the weakened algorithms should
>    be disabled from further use.
> 
> Can this document make stronger recommendations about deprecating certain
> algorithms such as 3-DES SHA-1 with normative language rather than keeping it
> in the "other" category in the profiles?

We updated Table 1 in Section 7.1 accordingly. Use of MD5, SHA-1, 3-DES, CAST-128, and RC5 is deprecated.
Therefore we propose updating the section as follows.

Old
   It is recognized that there may be older CMP implementations in use
   that conform to the algorithm use profile from Appendix D.2 of
   RFC 4210 [RFC4210].  For example, the use of AES is now mandatory for
   PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory.  In most
   cases the newer mandatory algorithms were listed as "other"
   algorithms in RFC 4210 [RFC4210].  Therefore, it is expected that
   many CMP systems may already support the recommended algorithms in
   this specification.  In such systems the weakened algorithms should
   be disabled from further use.  If critical systems cannot be
   immediately updated to conform to the recommended algorithm use
   profile, it is recommended a plan to migrate the infrastructure to
   conforming profiles be adopted as soon as possible.

New
   It is recognized that there may be older CMP implementations in use
   that conform to the algorithm use profile from Appendix D.2 of
   RFC 4210 [RFC4210].  For example, the use of AES is now mandatory for
   PROT_SYM_ALG but in RFC 4210 [RFC4210] 3-DES was mandatory. 
   Therefore, it is expected that
   many CMP systems may already support the recommended algorithms in
   this specification.  In such systems the weakened algorithms should
   be disabled from further use.  If critical systems cannot be
   immediately updated to conform to the recommended algorithm use
   profile, it is recommended a plan to migrate the infrastructure to
   conforming profiles be adopted as soon as possible.

Hendrik

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 5 Nov 2021 12:32:08 +0000

Hi!

> -----Original Message-----
> From: Brockhaus, Hendrik <[email-masked]>
> Sent: Thursday, November 4, 2021 2:04 PM
> To: Roman Danyliw <[email-masked]>
> Cc: LAMPS WG <[email-masked]>
> Subject: AW: AD review of draft-ietf-lamps-cmp-algorithms-07
> 
> Roman
> 
> > I did an AD review of draft-ietf-lamps-cmp-algorithms-07 with my
> > comments below.  Thanks for this work to evolve CMP.
> >
> > ** Section 7.  I would have benefit from a bit more clarity on the
> > direction provided in this section.
> >
> > -- "The following criteria will help implementers choose appropriate
> > algorithms for managing certificates"
> >
> > The bulleted list seems like only part of the criteria.  As a
> > non-exhaustive list, additional considerations might be the
> > capabilities of the end-point (e.g., does the target deployment have
> > hardware acceleration for some, are some algorithms simply out of
> > reach due to available compute or expected software support); or perhaps
> local policy or compliance requirements?
> >
> > It seems like some words are missing here.  Is the intent here to
> > guide the selection towards the algorithm that provides the minimum
> > amount of strength relative to the needed security requirements?
> 
> In addition to that we think another table in the introduction of Section 7
> listing the different algorithms sorted by its security level (bits of security)
> would help. We plan to present such a table during the LAMPS session for
> further discussion.
> 
> Old:
> The overall cryptographic strength of a CMP deployment will depend on several
> factors, including:
> 
> To avoid consuming too much computational resources it is recommended to
> choose a set of algorithms offering roughly the same level of security. Below
> are provided several algorithm profiles which are balanced, assuming the
> implementor chooses MAC secrets and / or certificate profiles of at least
> equivalent strength.

Works for me.  Thanks.

> >
> > ** Section 7.1.  The text in this section seems it should explicit say
> > that it is updating RFC4210.
> >
> > OLD

Thanks.

> >
> > ** Section 7.1.  If an algorithm is listed in the "Change from 4210"
> > column, should it be considered the equivalent of being added to the
> > "other" column (per Appendix D.2 of RFC4210?  If so, please be explicit about
> that.
> 
> We will delete the column "Changes from 4210" and introduced two columns,
> "Optional" and "Deprecated". "Deprecated" contains all algorithms define in
> RFC 4210 Appendix D.2 which SHOLUD NOT be used any more.

That's even a better.  

> > Change-from-4210 column for the MSG_MAC_ALG row?  It was already the
> > MTI in RFC4210.  Same question and situation with D-H for the
> PROT_ENC_ALG row.
> 
> > -- Editorial.  In PROT_SYM_ALG and SYM_PENC_ALG, the "3-DES
> > (3-key-EDE), CBC Mode" should read "3-DES (3-key-EDE, CBC mode)" per the
> text in RFC4210.
> 
> This is the Update we propose for Section 7.1 Old
> +============+===============+==========+=================+========
> =====
> ++
> +============+===============+==========+=================+========
> =====
> ++

I really like this table.  It's much clearer.

> Currently we propose a mandatory algorithm use profile with 112bit strength.
> As recommendations are going from RSA2048 to RSA3072 we discussed, if it is
> better to make a profile mandatory offering 128 bit strength.
> Currently we also mandate to use AES256 for key-wrap and encryption for
> delivering centrally generated RSA2048 keys pairs. The encryption is stronger
> than delivered key pair. Should we mandate AES128 only?

Can you be more specific on which text says profiles have 112bits of strength and the KeyWrap+RSA guidance?  Is the 112bits implicitly derived from using RSA-2048?

AES128 + RSA2048 would be more consistent based on the principle of matching relative key strength. However, if prior specs said AES256+RSA2048, I think we should be careful about weaking the requirement regardless of consistency.

> Currently HMAC and X9.9 are listed as OPTIONAL for MSG_MAC_ALG as they
> were listed in RFC 4210 D.2. We propose to remove x9.9 and keep HMAC.
> Regarding use of HMAC we would propose adding a Security Consideration as
> follows.
> 

I'm fine with keeping HMAC.  I don't really know much about the user community of X9.9.  It doesn't look like something we're recommend now.  When you say remove it, do you mean SHOULD NOT/Deprecate column?  We should also likely confirm that with the WG.

> > ** Section 9.  Can a reference be added for the theoretical weakness
> > in PasswordBasedMac?
> 
> We are not aware of any clear description of PasswordBasedMac weakness.
> Therefor we propose the following change:
> 
> Old
> When using MAC-based message protection the use of PBMAC1 is preferable
> to that of PasswordBasedMac. First, PBMAC1 is a well-known scrutinized
> algorithm, which is not true for PasswordBasedMac. Second, the
> PasswordBasedMac algorithm as specified in RFC 4211 section 4.4 is essentially
> PBKDF1 (as defined in RFC 2898 section 5.1) with an HMAC step at the end.
> Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in RFC
> 8018. PBKDF2 is superior to PBKDF1 in an improved internal construct for
> iterated hashing, and in removing PBKDF1's limitation of only being able to
> derive keys up to the size of the underlying hash function. Additionally, PBKDF1
> is not recommended for new applications as stated in Section 5 of RFC 8018
> and no longer an approved algorithm by most standards bodies, and therefore
> presents difficulties to implementors who are submitting their CMP
> implementations for certification, hence moving to a PBKDF2-based
> mechanism. This change is in alignment with RFC 9045 which updates RFC
> 4211 to allow the use of PBMAC1 in CRMF.

This is much clearer.  Thanks.

> >
> > ** Section 9.  Editorially, the first paragraph ("RFC 4210 Appendix
> > D.2 ...) and the two paragraphs of "In Section 7 ..." and "To keep the
> > list ...", seem to be saying the same thing.  Recommend a merge.
> >
> 
> > Can this document make stronger recommendations about deprecating
> > certain algorithms such as 3-DES SHA-1 with normative language rather
> > than keeping it in the "other" category in the profiles?
> 

Thanks for the text.

Regards,
Roman

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 5 Nov 2021 17:59:40 +0000

Hi Roman!

> AES128 + RSA2048 would be more consistent based on the principle of matching relative key strength. However, if prior specs said AES256+RSA2048, I think we should be careful about weaking the requi…

A couple thoughts here:

1. I don't think we have any language stating that these profiles are requirements. The language (from Hendrik's slides for Monday) is the column header " Recommended for
managing keys up to". It's a nit-pick, I know.

2. An implementation doing AES256+RSA2048 exceeds the profile that recommends AES128+RSA2048. That's fine, unless there's an on-the-wire interop concern here? For example if an existing CMP client handling RSA2048 keys only has an AES256 implementation and would barf if the server suddenly started using AES128? I assume that sort of thing would be caught in product testing.

Or is your concern more to do with optics / security proofs / FIPS and CMVP style certifications if we lower the required AES strength of a profile?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Roman Danyliw
Sent: November 5, 2021 7:32 AM
To: Brockhaus, Hendrik <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] AD review of draft-ietf-lamps-cmp-algorithms-07

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Hi!

> In addition to that we think another table in the introduction of
> Section 7 listing the different algorithms sorted by its security
> level (bits of security) would help. We plan to present such a table
> during the LAMPS session for further discussion.
>
> Old:
> To avoid consuming too much computational resources it is recommended
> to choose a set of algorithms offering roughly the same level of
> security. Below are provided several algorithm profiles which are
> balanced, assuming the implementor chooses MAC secrets and / or
> certificate profiles of at least equivalent strength.

Works for me.  Thanks.

> >
> > ** Section 7.1.  The text in this section seems it should explicit
> > say that it is updating RFC4210.
> >
> > OLD

Thanks.

> We will delete the column "Changes from 4210" and introduced two
> columns, "Optional" and "Deprecated". "Deprecated" contains all
> algorithms define in RFC 4210 Appendix D.2 which SHOLUD NOT be used any more.

That's even a better.

> As recommendations are going from RSA2048 to RSA3072 we discussed, if
> it is better to make a profile mandatory offering 128 bit strength.
> Currently we also mandate to use AES256 for key-wrap and encryption
> for delivering centrally generated RSA2048 keys pairs. The encryption
> is stronger than delivered key pair. Should we mandate AES128 only?

> Regarding use of HMAC we would propose adding a Security Consideration
> as follows.
>

> preferable to that of PasswordBasedMac. First, PBMAC1 is a well-known
> scrutinized algorithm, which is not true for PasswordBasedMac. Second,
> the PasswordBasedMac algorithm as specified in RFC 4211 section 4.4 is
> essentially
> Here we update to use the PBKDF2-HMAC construct defined as PBMAC1 in
> RFC 8018. PBKDF2 is superior to PBKDF1 in an improved internal
> construct for iterated hashing, and in removing PBKDF1's limitation of
> only being able to derive keys up to the size of the underlying hash
> function. Additionally, PBKDF1 is not recommended for new applications
> as stated in Section 5 of RFC 8018 and no longer an approved algorithm
> by most standards bodies, and therefore presents difficulties to
> implementors who are submitting their CMP implementations for
> certification, hence moving to a PBKDF2-based mechanism. This change
> is in alignment with RFC 9045 which updates RFC

> > D.2 ...) and the two paragraphs of "In Section 7 ..." and "To keep
> > the list ...", seem to be saying the same thing.  Recommend a merge.
> >
>
> > certain algorithms such as 3-DES SHA-1 with normative language
> > rather than keeping it in the "other" category in the profiles?
>

Thanks for the text.

Regards,
Roman

> Hendrik

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!NwM9O539Oeipl6SKmy8vetAtfLdTV8T7NN9QpjDYy5RiXvDZT0IQ7XKRqzUi-rLAqsGMhhAHTg$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 8 Nov 2021 11:11:34 +0000

Roman, Mike

> Von: Mike Ounsworth <[email-masked]>
> Gesendet: Freitag, 5. November 2021 19:00
> 
> Hi Roman!
> 
> > AES128 + RSA2048 would be more consistent based on the principle of
> matching relative key strength. However, if prior specs said AES256+RSA2048, I
> think we should be careful about weaking the requirement regardless of
> consistency.

As the algorithm use profile from RFC 4210 Appendix D.2 was not maintained for a long time, AES was just mentioned as a further alternative. The mandatory algorithm back then was 3-DES.
I am not aware of any document stating AES256 for transporting private keys. As it is a critical operation, one could recommend to use the maximum strength available, but we should mandate only strength comparable to the key transported. > 

> A couple thoughts here:
> 
> 1. I don't think we have any language stating that these profiles are
> requirements. The language (from Hendrik's slides for Monday) is the column
> header " Recommended for managing keys up to". It's a nit-pick, I know.

My understanding would be that at least the strength of the key to be managed should be used. Higher strength should also be allowed.

> 
> 2. An implementation doing AES256+RSA2048 exceeds the profile that
> recommends AES128+RSA2048. That's fine, unless there's an on-the-wire
> interop concern here? For example if an existing CMP client handling RSA2048
> keys only has an AES256 implementation and would barf if the server suddenly
> started using AES128? I assume that sort of thing would be caught in product
> testing.
> 
> Or is your concern more to do with optics / security proofs / FIPS and CMVP
> style certifications if we lower the required AES strength of a profile?

Hendrik