That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Eric,

I've reformatted the KEY GEN call (part of the prior message) to try and make sure it is clarified.

Key Gen - KEY FORM: OPEX
    KEYLEN : DOUBLE
    TYPE1  : EXPORTER
    TYPE2  : IMPORTER
    KEY ID1: LV
    KEK    : LABEL FOR EXPORTER UTILITY KEY  (DOUBLE LEN EXPORTER KEY WITH NOCV ATTRIBUTE)
    GEN-ID1: AFOREMENTIONED KEY TOKEN
    GEN-ID2: LV    LOW-VALUES (KEY-ID1)

Sincerely, 

Mark

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Eric,

I've made progress.  

I took the external IMPORTER key that I genned at the start and re-imported it back to an internal token.  

I passed that internal token as my source key.  And I've removed the unwrap key and its length.

It seems that using the external form of that same key with the exporter key I exported it with during the key gen, did not work. 

I cannot explain why one version works but the other does not.   I have every reason to believe either should work.

If you or someone can enlighten me, I'd love to hear it.

Sincerely,

Mark

Eric,

I've reformatted the KEY GEN call (part of the prior message) to try and make sure it is clarified.

Key Gen - KEY FORM: OPEX
    KEYLEN : DOUBLE
    TYPE1  : EXPORTER
    TYPE2  : IMPORTER
    KEY ID1: LV
    KEK    : LABEL FOR EXPORTER UTILITY KEY  (DOUBLE LEN EXPORTER KEY WITH NOCV ATTRIBUTE)
    GEN-ID1: AFOREMENTIONED KEY TOKEN
    GEN-ID2: LV    LOW-VALUES (KEY-ID1)

Sincerely, 

Mark

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Thanks for your patience. I completely lost track of this thread. Did you ever get this working?

Eric,

I've made progress.  

I took the external IMPORTER key that I genned at the start and re-imported it back to an internal token.  

I passed that internal token as my source key.  And I've removed the unwrap key and its length.

It seems that using the external form of that same key with the exporter key I exported it with during the key gen, did not work. 

I cannot explain why one version works but the other does not.   I have every reason to believe either should work.

If you or someone can enlighten me, I'd love to hear it.

Sincerely,

Mark

Eric,

I've reformatted the KEY GEN call (part of the prior message) to try and make sure it is clarified.

Key Gen - KEY FORM: OPEX
    KEYLEN : DOUBLE
    TYPE1  : EXPORTER
    TYPE2  : IMPORTER
    KEY ID1: LV
    KEK    : LABEL FOR EXPORTER UTILITY KEY  (DOUBLE LEN EXPORTER KEY WITH NOCV ATTRIBUTE)
    GEN-ID1: AFOREMENTIONED KEY TOKEN
    GEN-ID2: LV    LOW-VALUES (KEY-ID1)

Sincerely, 

Mark

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.

Eric,

First off, thanks for getting back to me.  I appreciate it.

And yes, I did get this working.  I've no idea why, but the TR34 export worked when I took the External Importer key I generated at the start (w/KGN) and imported it back into my master key to give me an operational importer key.   The TR34 took that operational importer key and it worked fine.

I would think that an operational importer key or using an external version of that importer key with an unwrap key would be equivalent since both would have the same clear key value.

Sincerely,

Mark

Thanks for your patience. I completely lost track of this thread. Did you ever get this working?

Eric,

I've made progress.  

I took the external IMPORTER key that I genned at the start and re-imported it back to an internal token.  

I passed that internal token as my source key.  And I've removed the unwrap key and its length.

It seems that using the external form of that same key with the exporter key I exported it with during the key gen, did not work. 

I cannot explain why one version works but the other does not.   I have every reason to believe either should work.

If you or someone can enlighten me, I'd love to hear it.

Sincerely,

Mark

Eric,

I've reformatted the KEY GEN call (part of the prior message) to try and make sure it is clarified.

Key Gen - KEY FORM: OPEX
    KEYLEN : DOUBLE
    TYPE1  : EXPORTER
    TYPE2  : IMPORTER
    KEY ID1: LV
    KEK    : LABEL FOR EXPORTER UTILITY KEY  (DOUBLE LEN EXPORTER KEY WITH NOCV ATTRIBUTE)
    GEN-ID1: AFOREMENTIONED KEY TOKEN
    GEN-ID2: LV    LOW-VALUES (KEY-ID1)

Sincerely, 

Mark

I think I understand your problem more clearly now. So, if you are trying to export (via TR-34 distribute) an IMPORTER, you would need DEC-ONLY, as you noted. If that IMPORTER is already external, you would need the IMPORTER key that matches the EXPORTER used in CSNBKGN.

A control vector violation tells me that one of the input keys doesn't meet the needs. This is a bit more complicated than is easy to solve in the community, but if you want to keep working here, I'm OK with that. What I need to know are the specific inputs for both KGN and T34D. I don't need to know key values or anything, but I need to know what the rules are, what kind of key is being used (external or internal, key types, any unique key attributes, etc) for each parm.

Eric,

I'm using a key gen call to create the DES key I want to export via TR-34 call CSNDT34D.   You are correct.

Sincerely,

Mark

Which callable service(s) are you using? You say "DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER".

Then you said "TR-34 export call to use the external IMPORTER key". Are you referring to TR-34 Key Distribution (CSNDT34D and CSNFT34D)?

I need to know the specific services and rules you are using to be able to understand where it is going sideways.

Eric,

Thanks for helping me out.   I'm sure the table applies to TR-34 in this case.  

The DES key I'm trying to export has the following settings during key gen:  OPEX, EXPORTER, IMPORTER.  I also provide a key token that I build with EXPORTER & NOCV settings for the operational EXPORTER key on the key gen command.   I think this gives me an operation exporter with a nocv attribute as one of the key pair.  And the other is an external token IMPORTER key, likely without the NOCV attribute.

I then pass the operational exporter key to the TR-34 as the source key, and using the ENC-ONLY flag.  This call completes successfully, but my partner doesn't like the TR-31 attribute of ENC-ONLY and wants me to use DEC-ONLY.

So I altered ENC-ONLY to DEC-ONLY to make the next call.  And I'm going to believe that the error returned (and noted above) probably means that DEC-ONLY and an EXPORTER key isn't a valid acceptable (or permitted?) combination thereby returning the error I noted above.

In my next test, I've altered the TR-34 export call to use the external IMPORTER key.  I've added the key unwrap exporter key to the parmlist.   I've left the DEC-ONLY parameter on the rule list.

I now get a x27/39 (Control Vector Violation) error on this new version of the call.   And I'm wondering if this error might be because my external IMPORTER key does not have the NOCV attribute.  And that maybe I need to build a key token for this half of the key pair as well.  

Does this sound reasonable or should I be looking elsewhere?

Sincerely,

Mark

That column is the ACP number (in hex) for the operation listed to the left. That said, that table is for TR-31 Import. Can you say which service you are using? I suspect that table is unrelated to the service you are using.