Subject: RFC 2511: PKIArchiveOptions encoding?

From: "denis bider" <[email-masked]>
Date: Tue, 16 May 2000 15:15:57 +0200

Hello,

I am reading RFC 2511 and trying to understand how to properly parse the
PKIArchiveOptions choice field. For your convenience, I am attaching the
relevant ASN.1 definitions at the end of this message.

PKIArchiveOptions is a CHOICE with three possible value types, each of which
is implicitly tagged ([0], [1], [2]). Now, the problem is, the first one of
these types, [0] EncryptedKey, is a CHOICE as well. Now, EncryptedKey has
two possible value types with two possible tags among them. One possibility,
EnvelopedData, has an implicit tag of [0], and the other one,
EncryptedValue, is a SEQUENCE.

My question is - how does this fit together? I see two possibilities:
  - The clean one: the EncryptedKey type within PKIArchiveOptions is
actually not implicitly tagged, but rather is explicitly tagged, because it
is a CHOICE within a CHOICE. However, this fact is not stated in the ASN.1
definition because there is some clause in the ASN.1 specification that
already says that this applies in such cases. (Unfortunately, I do not have
access to such an ASN.1 specification.)
  - The dirty one: the EncryptedKey type within PKIArchiveOptoins is indeed
implicitly tagged. Therefore, it actually has two possible tags: [0] if the
sub-type being used is EnvelopedData, and SEQUENCE if the sub-type being
used is EncryptedValue.

Is there someone here who would care to point me in the right direction?

Also, I would be glad if someone could enumerate some real-world
implementations of RFC 2511; it would be great if I could test my
implementation against others that are already proven.

Note: I tried searching the archives, but the archive site turned out to be
rather useless. The only feasible way to search the archives is to scan the
subject lines, which are on 13 different pages, for keywords that one might
only hope will appear in the subject of a related message. The only
alternative is to download the entire archive file and search that file with
one's favourite tools. However, at a file size of 16 MB and a throughput of
10KB per second this is not a very appealing alternative.

Kind regards,

denis bider

Some relevant ASN.1 definitions:

PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedKey,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN }
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
      encryptedValue        EncryptedValue,
      envelopedData     [0] EnvelopedData }
      -- The encrypted private key MUST be placed in the envelopedData
      -- encryptedContentInfo encryptedContent OCTET STRING.

EncryptedValue ::= SEQUENCE {
   ...
}

---

From: Carlisle Adams <[email-masked]>
Date: Tue, 16 May 2000 14:20:03 -0400

Hi Denis,

Your first alternative below ("the clean one") is correct:  tagging is
EXPLICIT in a CHOICE.  If you don't have the ASN.1 specifications, there are
a number of publicly-available books and tutorials on the subject.  One such
example is the book "ASN.1:  The Tutorial and Reference" by Douglas Steedman
(1990) -- see pages 66-67 for a discussion on this particular issue.

Carlisle.

P.S., As for real-world implementations of 2511 for interoperability testing
purposes, you can join the CMP/CRMF interop trials that have been on-going
for some time now.  Contact Bob Moskowitz ([email-masked]) or the PKI Forum
(http://www.pkiforum.org) for further details.

> ----------
> From: 	denis bider[SMTP:[email-masked]]
> Sent: 	Tuesday, May 16, 2000 9:15 AM
> To: 	[email-masked]
> Subject: 	RFC 2511: PKIArchiveOptions encoding?
> 
> Hello,
>