All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael

All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael

Hi Tim,

If I understand you correctly, you're saying that PKCS#11 implementations are taking the source type and the source data, ASN.1 encoding them, and using that value as the label? As opposed to the calling applications just providing the label value?

Thanks!

Sincerely,

Jonathan

All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael

I took a look at the source for NSS and, as far as I can tell, it's simply taking pSourceData and ulSourceData and passing them through to the OAEP Encode/Decode functions as the label. It's not doing any ASN.1 processing (encoding or decoding). It appears to treat pSourceData as the label and ulSourceData as the length. 

The structure hasn't changed, it's backwards compatible especially if there's a note added that for greatest compatibility clients should set deprecated to 1. 

Jonathan

Hi Tim,

If I understand you correctly, you're saying that PKCS#11 implementations are taking the source type and the source data, ASN.1 encoding them, and using that value as the label? As opposed to the calling applications just providing the label value?

Thanks!

Sincerely,

Jonathan

All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael

Hi,

The NSS implementation makes sense to me and is consistent with how we handle it, and how most of the customers I've interacted with expect it to behave.  Although that doesn't necessarily mean we aren't using it incorrectly.

From my understanding, the CK_RSA_PKCS_OAEP_SOURCE_TYPE directly maps to the PKCS1PSourceAlgorithms in the ASN.1 encoding.  Today there is only one source type defined, which is "specified" in PKCS#1, the RFC and PKCS#11.  So while the CK_RSA_PKCS_OAEP_SOURCE_TYPE could be argued as being useless as there is only one source type defined today. The underlying standards PKCS#1 and the RFC both specify this type as something that can be expanded in the future.  So for that reason alone, I don't consider it as useless nor that we should deprecate it. 

As for the value of pSourceData and ulSourceDataLen in PKCS#11, PKCS#11 documents it as "input for the encoding parameter source".  To me, that maps back to the standards very well. If it was documented as the "label", than that might provide complications/limitations in the future if the source type is ever expanded.  As it is defined today, it is very clear that it is the input to the EncodingParameters; whatever that may be.  With the way "specified" is defined today, the input to the "EncodingParameters" is either a octet string or the empty string; which is the label. So it seems explicit and deterministic.

Thanks

Darren

I took a look at the source for NSS and, as far as I can tell, it's simply taking pSourceData and ulSourceData and passing them through to the OAEP Encode/Decode functions as the label. It's not doing any ASN.1 processing (encoding or decoding). It appears to treat pSourceData as the label and ulSourceData as the length. 

The structure hasn't changed, it's backwards compatible especially if there's a note added that for greatest compatibility clients should set deprecated to 1. 

Jonathan

Hi Tim,

If I understand you correctly, you're saying that PKCS#11 implementations are taking the source type and the source data, ASN.1 encoding them, and using that value as the label? As opposed to the calling applications just providing the label value?

Thanks!

Sincerely,

Jonathan

All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael

Hi,

This is a good discussion! 

I'm still not seeing the purpose of the parameter if the data is just passed through as the label. There's a theoretical where some other way of providing the label would happen, there would be a different source type, and then the PKCS#11 implementations would need to interpret whatever that is to come up with the label it uses (presumably parsing some ASN.1). OTOH, we can cut off that path now and simply state that the PKCS#11 API takes the label. If someone invents some new ASN.1 gunk to pass the label around in their protocol, they can deal with it rather than the PKCS#11 implementers. 

pSourceData is the content of the OCTET string or the label encoded as an OCTET string? Do I pass in a byte array containing just the label or do I pass in 0x04,len,Label?

Jonathan

Hi,

The NSS implementation makes sense to me and is consistent with how we handle it, and how most of the customers I've interacted with expect it to behave.  Although that doesn't necessarily mean we aren't using it incorrectly.

From my understanding, the CK_RSA_PKCS_OAEP_SOURCE_TYPE directly maps to the PKCS1PSourceAlgorithms in the ASN.1 encoding.  Today there is only one source type defined, which is "specified" in PKCS#1, the RFC and PKCS#11.  So while the CK_RSA_PKCS_OAEP_SOURCE_TYPE could be argued as being useless as there is only one source type defined today. The underlying standards PKCS#1 and the RFC both specify this type as something that can be expanded in the future.  So for that reason alone, I don't consider it as useless nor that we should deprecate it. 

As for the value of pSourceData and ulSourceDataLen in PKCS#11, PKCS#11 documents it as "input for the encoding parameter source".  To me, that maps back to the standards very well. If it was documented as the "label", than that might provide complications/limitations in the future if the source type is ever expanded.  As it is defined today, it is very clear that it is the input to the EncodingParameters; whatever that may be.  With the way "specified" is defined today, the input to the "EncodingParameters" is either a octet string or the empty string; which is the label. So it seems explicit and deterministic.

Thanks

Darren

I took a look at the source for NSS and, as far as I can tell, it's simply taking pSourceData and ulSourceData and passing them through to the OAEP Encode/Decode functions as the label. It's not doing any ASN.1 processing (encoding or decoding). It appears to treat pSourceData as the label and ulSourceData as the length. 

The structure hasn't changed, it's backwards compatible especially if there's a note added that for greatest compatibility clients should set deprecated to 1. 

Jonathan

Hi Tim,

If I understand you correctly, you're saying that PKCS#11 implementations are taking the source type and the source data, ASN.1 encoding them, and using that value as the label? As opposed to the calling applications just providing the label value?

Thanks!

Sincerely,

Jonathan

All,

After reviewing the PKCS#11 specification and RFC 8017 we've concluded that the source parameter of CK_RSA_PKCS_OAEP_PARAMS is useless and that pSourceData and ulSourceDataLen would be better as pLabel and ulLabelLen. This would align with inputs to the RSAES-OAEP-ENCRYPT and RSAES-OAEP-DECRYPT operations defined in RFC 8017 sections 7.1.1 and 7.1.2, respectively.

We propose the following:

1. Remove CKZ_DATA_SPECIFIED, CK_RSA_PKCS_OAEP_SOURCE_TYPE, and Table 37
2. Change the CK_RSA_PKCS_OAEP_PARAMS structure to

CK_RSA_PKCS_OAEP_PARAMS is a structure that provides the parameters to the CKM_RSA_PKCS_OAEP mechanism.  The structure is defined as follows:

typedef struct CK_RSA_PKCS_OAEP_PARAMS {

   CK_MECHANISM_TYPE            hashAlg;

   CK_RSA_PKCS_MGF_TYPE         mgf;

   CK_ULONG                     deprecated;

   CK_VOID_PTR                  pLabel;

   CK_ULONG                     ulLabelLen;

}  CK_RSA_PKCS_OAEP_PARAMS;

The fields of the structure have the following meanings:

                                    hashAlg       mechanism ID of the message digest algorithm used to calculate the digest of the encoding parameter

                                          mgf          mask generation function to use on the encoded block

                          deprecated         this value (formerly source) is to be ignored

                                  pLabel           pointer to a label associated with the message; it must be NULL_PTR if the caller wants the default label (the empty string) to be used (as per RFC 8017)

                           ulLabelLen         length in bytes of the data pointed to by pLabel; it must be 0 if the caller wants the default label (the empty string) to be used (as per RFC 8017)

CK_RSA_PKCS_OAEP_PARAMS_PTR is a pointer to a CK_RSA_PKCS_OAEP_PARAMS.

The only references we find to "source" and "encoding parameters" in RFC 8017 are in section A.2.1 which details how to ASN.1 encode OAEP parameters. We think the original PKCS#11 language was incorrectly drawn from here rather than the sections describing the actual inputs to the encoding functions.

Sincerely,

Jonathan and Michael