Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions

From: Pat Calhoun <[email-masked]>
Date: Mon, 3 Sep 2001 11:11:22 -0700

> of course that adding an S/MIME and CMS introduction would be
> unnecessary. Some precisions either:
> 
> - While there's a specific mention of MIME encoding of AVPs in 6.1
> (CMS-Signed-Data AVP):
> 
>   This means that where a set of AVPs is protected using CMS, the set
>   MUST first be encoded according to MIME encoding rules specified
> below.

correct.

> 
> and in the same paragraph (though talking about encryption + signing):
> 
>   The resulting CMS object MUST then be MIME encoded producing an
>   application/pkcs7-mime MIME type which is then used as the content
>   of the EnvelopedData. 

right.

> 
> there's no explicit mention of MIME enconding in 6.2
> (CMS-Encrypted-Data AVP). My oppinion is that such explicit mention to
> MIME should be included in 6.2 (at least if MIME enconding is
> necessary).

ok, here's the scoop (as I understand it). 6.1 specifies how the
CMS-Signed-Data AVP is created. This is done by taking a bunch of AVPs,
putting them through the signing transform, and taking the result, which
is included in the AVP itself. However, the AVPs themselves are never encoded
in any MIME format when included in the message.

6.2, on the other hand, is completely different. The encrypted data is
included in the CMS-Encrypted-Data AVP.

So, in 6.1 the process is different from 6.2.

I believe that Stephen will need to help us out here with any additional
clarifications.

> 
> BTW, where are the MIME encoding rules specified "below"?

ok, that was wrong, and I've included the references to MIME, which discusses
the encoding mechanisms.

As far as the intro paragraph, I've come up with the following at the end
of section 1.0:

This Diameter application makes use of Cryptographic Message
Syntax (CMS), which a method used to secure MIME (S/MIME) 
messages. This application was designed to allow for Diameter
implementations to use existing S/MIME toolkits in order to
comply with this specification.

so, we're nearly there.

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Tue, 04 Sep 2001 16:14:40 +0200

Pat Calhoun wrote:
> 
> > there's no explicit mention of MIME encoding in 6.2
> > (CMS-Encrypted-Data AVP). My opinion is that such explicit mention to
> > MIME should be included in 6.2 (at least if MIME encoding is
> > necessary).
> 

Right. A CMS SignedData structure is created containing only the
digest of the AVPs, not the whole bunch of AVPs.

> So, in 6.1 the process is different from 6.2.

Really? In the sense that S/MIME isn't involved? Just pure CMS?

> I believe that Stephen will need to help us out here with any additional

I'm afraid I'm beginning to need it.

Let's say that there are a encapsulation message syntax called CMS. It
provides six content-types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data. This syntax
evolves from PKCS#7 and makes use of ASN.1.

Let's imagine that a messaging standard, S/MIME, takes just two of the
content types (signed-data and enveloped-data) to provide secure
messaging (as well as a particular singed-data message,
certificates-only). Of course that some kind of MIME encoding is
necessary.

Finally, AAA-WG says that it will use CMS for providing end-to-end
security. However, two significant things are also stated: that the
secured AVPs will be CMS-Signed-Data, CMS-Encrypted-Data and CMS-Cert
(which coincide with the different structures used by S/MIME) and that
"This application was designed to allow for Diameter implementations
to use existing S/MIME toolkits".

My first impression is that S/MIME encoding was an intermediate step
to get our secured AVP (that is the reason why I thought that S/MIME
Security Application was a more proper name). However, it looks that,
in order to get a CMS-Encrypted-Data AVP, no S/MIME processing is
necessary.

Now, I'm definitely confused (I admit that I'm not an S/MIME expert).
But I'd like to know where S/MIME processing is used, where not (and
how to encode several EnvelopedData values within a single
CSM-Enveloped-Data AVP; is that an S/MIME method or not)

> Syntax (CMS), which a method used to secure MIME (S/MIME)
                    ^^^
                       | something missed?

> so, we're nearly there.

Right :-))

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Sep 2001 18:51:49 +0100

Miguel,

I've spoken to Pat about this (and though it seemed clear 
enough to me it really wasn't:-). I also checked with the 
S/MIME WG to make sure we're doing the "right" thing with
MIME encodings so that we can more easily re-use existing
toolkits in our context.

First the background then the suggested text to include:

- CMS is a generic cryptographic message format, that makes
no reference to MIME. We're using a small subset of the
options available in CMS.
- The S/MIME v3 message specification tells you how MIME and
CMS can be used together to do secure email. There are many
toolkits which implement this specification, and some of 
the older ones don't really handle the "bare" CMS cases
very well (they assume you want MIME encoding).

For these reasons the current draft uses the following scheme
for the CMS-Encrypted-Data AVP (similar considerations apply
for the CMS-Signed-Data AVP):

- Marshall up (catenate) the set of to-be-encrypted AVPs
- Encode those using MIME encoding and use the id-data
  object identifier (another place where the older toolkits 
  go wrong, some only handle id-data and insist on 
  MIME en/de-coding the to-be-encrypted data)
- Wrap that using CMS EnvelopedData
- Put the result into a CMS-Encrypted-Data AVP

If we don't want to do the MIME encoding then we can omit
it, but someone someday might build using a toolkit that
forces the MIME en/decoding and we'll have more interop 
problems than otherwise. (I personally don't mind whether
we omit the MIME encoding or not.)

The attached re-wording of sections 6.1/6.2 should
hopefully clarify this.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Insert into section 6.0:

   The profile of CMS algorithm and structure usage is conformant to 
   that specified in the S/MIME v3 message specification [11]. This
   makes is simpler to base an implementation of this specification 
   upon an existing S/MIME toolkit.
   
   All MIME encoded data in this specification MUST use the 
   "application/pkcs7-mime" MIME type.

6.1  CMS-Signed-Data AVP

   The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and
   contains the Basic Encoding Rules (BER) encoding of a CMS object [3]
   of type ContentInfo.  This means that where a set of AVPs is to be
   signed, the set of AVPs with the 'P' bit set MUST first be catenated 
   together in the order in which they occur in the Diameter message 
   and MUST then be encoded according to MIME encoding rules specified 
   in [16,17]. The result of this encoding is used as input into the 
   signing process. 
   
   Note that the AVPs themselves are not encapsulated within the 
   CMS-Signed-Data AVP. Instead, the digest value of the AVPs
   produced in the signature process MUST be included in the CMS-Signed-
   Data AVP, as a message-digest attribute (defined in section 11.2 of
   [3]) in the SignerInfo value.

   Multiple Diameter entities MAY add their signatures to an existing
   CMS-Signed-Data AVP. Multiple signatures are added within the
   countersignature attribute (defined in section 11.4 of [3]) and not
   as additional SignerInfo values. The countersignature attribute
   requires that the signatures occur sequentially, meaning that each
   signature covers the existing signatures in the CMS object.

   The initial signature, and any additional countersignatures, MUST
   cover the exact same set of AVPs, in the order they are present in
   the message.

   Note that the CMS-Signed-Data AVP itself MUST NOT be used in the 
   generation of the signature, and therefore MUST NOT have its 'P' bit set.

   The eContent field of the EncapsulatedContentInfo structure MUST be
   absent since the digital signature covers data outside of the object.
   The signature is computed over all AVPs with the 'P' bit enabled. The
   order of the AVPs MUST be preserved and the computation begins with
   the first AVP immediately following the Diameter header. 

   If a receiver detects that the contents of the CMS-Signed-Data AVP
   are invalid, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP 
   value defined in section 7.1.

   When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data
   AVP MUST be created first. This AVP MUST then have the 'P' bit set
   and be one of the inputs to the signing process as described above.
   (Any other processing resulting in the same output can be used.) This 
   means that signing is "outside" encryption.

   No more than one CMS-Signed-Data AVP MUST be present in any given
   Diameter message.

6.2  CMS-Encrypted-Data AVP

   The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and
   contains the Basic Encoding Rules (BER) encoding of a CMS object [3]
   of type ContentInfo.

   All AVPs to be encrypted are concatenated. This value is then MIME
   encoded (according to the rules specified in [16,17]) and then encrypted 
   according to normal CMS rules, and then used as the value of the 
   EncryptedContent field within EnvelopedData. The contentType of the 
   EncryptedContentInfo value MUST be id-data [11].

   A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or 
   more AVP would be encrypted within separate EnvelopedData structures, then 
   separate CMS-Encrypted-Data AVPs MUST be used. 
   
   Thus, implementations MUST be able to support the presence of multiple 
   CMS-Encrypted-Data AVPs and MUST be able to decrypt any EnvelopedData 
   for which it is a recipient, as indicated in the EnvelopedData's 
   RecipientInfos field [3].

   If the recipient is not specified in a RecipientInfo, it MAY choose
   to process the message or return an answer with the Result-Code AVP
   set to DIAMETER_NO_DSA_RECIPIENT. If the recipient is in the
   RecipientInfos and an error occurs during decryption, then the
   recipient MUST answer with the Result-Code set to
   DIAMETER_INVALID_AVP_VALUE.

   Diameter nodes SHOULD implement content encryption key reuse (see
   section 3.4 above).

   If a receiver detects that the contents of the CMS-Encrypted-Data AVP
   is invalid, it SHOULD answer with the Result-Code set to
   DIAMETER_INVALID_AVP_VALUE.

   Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter
   message.

6.x Example encodings

   In order to clarify contents of and the relationships between 
   CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following
   example of how these AVPs are calculated.
   
   First, some short-hand:

	- MIME(x) represents the MIME encoding of x 
	- EnvelopedData-fnc(x,y) represents the EnvelopedData produced
	as output of a function with x as the to-be-encrypted-data
	and y as the parameters (e.g. recipient information).
	- SignedData (y) represents the SignedData produced
	as output of a function with the catenation of the 'P is set' 
	AVPS as the to-be-digested-data	(which is not part of the 
	output!) and y as the parameters (e.g. signer information).

    The scenario calls for a message containing 7 AVPs s,t,e,p,h,e and n
    to meet the following: 
	AVPs s,t and e are to be encrypted for recipient P.
	AVPs e,p and h are to be encrypted for recipient A.
	AVPs s,e (2nd time:-) and n are to be signed by originator T.
    
    The resulting message will look like:
    
	AVP1='P is set',   EnvelopedData-fnc(MIME(s,t,e),P)
	AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A)
	AVP3='P is set',   e
	AVP4='P is clear', n
	AVP5='P is clear', SignedData(T)
    
    The result of this is that AVPs t,e(1st time), p and h are actually
    signed even though that wasn't required. However, this is no harm.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 11:35:18 +0200

> The attached re-wording of sections 6.1/6.2 should

----------------------------------------------------------------------

>    in [16,17]. The result of this encoding is used as input into the

I assume that references 16 and 17 has been added. Could you post such
references?

>    value defined in section 7.1.

Well, here I'd suggest leaving something more similar to the old text.
Something like:

   If a receiver cannot verify correctly the signature carried by the 
   CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH 
   Result-Code AVP value defined in section 7.1.

Just because there can be some confusion between the following
existing errors:

      DIAMETER_INVALID_CMS_DATA          5019
         This error code is returned when a CMS-Data AVP is received
         with an invalid ContentInfo object.

and

      DIAMETER_INVALID_AUTH             4012
         The signature in the CMS-Signed-Data AVP is invalid.

>    according to normal CMS rules, and then used as the value of the
                                    ^^^^^^^^
                                   maybe too many "and then"

>    separate CMS-Encrypted-Data AVPs MUST be used.

Well, it has been stated above that all AVPs to be encrypted are
concatenated, encoded, encrypted and used as the Encrypted Content  of
EnvelopedData. Maybe the second paragraph should be rephrased to say
"All AVPs to be encrypted in a given AVP are concatenated"

>    DIAMETER_INVALID_AVP_VALUE.

This solves issue 174.

>    is invalid, it SHOULD answer with the Result-Code set to
     ^^^
     are
>    DIAMETER_INVALID_AVP_VALUE.

Shouldn't they be DIAMETER_INVALID_CMS_DATA?

>         AVPs s,e (2nd time:-) and n are to be signed by originator T.

I'd use subindexes:

    The scenario calls for a message containing 7 AVPs s,t,e1,p,h,e2
and n
    to meet the following:
        AVPs s,t and e1 are to be encrypted for recipient P.
        AVPs e1,p and h are to be encrypted for recipient A.
        AVPs s,e2 and n are to be signed by originator T.

Additionally, I think that information about who has requested a
digital signature should be added.

>         AVP5='P is clear', SignedData(T)

        AVP1='P is set',   EnvelopedData-fnc(MIME(s,t,e1),P)
        AVP2='P is clear', EnvelopedData-fnc(MIME(e1,p,h),A)
        AVP3='P is set',   e2
        AVP4='P is clear', n
        AVP5='P is clear', SignedData(T)

In this example, P would get s,t,e1,e2 and n with a digital signature
(either direct or indirect) on only s,t,e1 and e2 (although there is a
digital signature on p and h, P isn't able to decrypt AVP2, so that it
won't get p and h).

In turn, A would get e1,p,h,e2 and n with a digital signature on e2 (A
is not able to decrypt AVP1)

>     signed even though that wasn't required. However, this is no harm.

As a conclusion, I'd add information about who is the receiver of the
digital signature, would change the protection bit of AVP4 (n) and
would rephrase the last paragraph in order to add such informations...

Regards

-- 
  Miguel Angel Monjas Llorente
  Systems Engineer, GSM/UMTS Systems Management
  Ericsson España, S.A. (EEM) UMTS/GSM Databases
  Tel: +34 91 3393605                 Mob: +34 629 570196
  <mailto:[email-masked]>  Fax: +34 91 3392538
  Ombú 3, 10th. 28045 Madrid - SPAIN -

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 10:59:25 +0100

Miguel,

> I assume that references 16 and 17 has been added. Could you post such

Sorry they were from Pat's working copy:

.IP [16]
N. Freed, N. Borenstein, " MIME Part 1: Format of Internet Message
Bodies", RFC 2045, November 1996.
.IP [17]
N. Freed, N. Borenstein, " MIME Part 2: Media Types", RFC 2046, November 1996.

> "All AVPs to be encrypted in a given AVP are concatenated"

I prefer the existing text here.

> > 6.x Example encodings

I fixed some errors here, not quite the way you asked.

> would rephrase the last paragraph in order to add such informations...

There's no concept of the "receiver" of a digital signature. Anyone can
verify a signature. It is true that sometimes that encrypting and 
signing will mean that some stuff that was signed isn't visible to
some verifiers, but that's presumably the correct situation.

Regards,
Stephen.

Insert into section 6.0:

6.1  CMS-Signed-Data AVP

   All AVPs to be encrypted are concatenated. This value is then:
   
   	- MIME encoded (according to the rules specified in [16,17]),
   	- encrypted according to normal CMS rules, 
   	- used as the value of the  EncryptedContent field within 
   	  EnvelopedData. 
   
   The contentType of the EncryptedContentInfo value MUST be id-data [11].

   If a receiver detects that the contents of the CMS-Encrypted-Data AVP
   are invalid, it SHOULD answer with the Result-Code set to
   DIAMETER_INVALID_CMS_DATA.

6.x Example encodings

   First, some short-hand:

	AVPs as the to-be-digested-data	(which is not part of the 

    The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n
    to meet the following: 
	AVPs s, t and e are to be encrypted for recipient P.
	AVPs e, p and h are to be encrypted for recipient A.
	AVPs s, e' and n are to be signed by originator T.

	AVP3='P is set',   e'
	AVP4='P is set',   n
    
    The result of this is that AVPs s,t,e,e' and n are actually
    signed even though signing of t and e wasn't required. However, 
    this is no harm.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 15:24:16 +0200

> some verifiers, but that's presumably the correct situation.

OK. This is right in a wide sense but it's necessary to take into
account that Diameter CMS Security employs widely DSAs. The two
participants usually request some kind of protection (AVPs to be
protected and means to get the protection). In such a scenario, there
is a "receiver" of the digital signature (the participant that has
requested it).

>         AVP5='P is clear', SignedData(T)

Let's imagine that this scenario happens withing a DSA established
between T and P. P has requested a digital signature on s, e' and n
and encryption on s, t and e.

The resulting message will comply with the requests:

- Encryption of s, t and e (AVP1)
- Digital signature on s, t, e, e' and n.

What about if the DSA has been established between T and A. A has
requested a digital signature on s, e' and n and encryption on e, p
and h. The resulting message won't comply with the requests:

- Encryption of e, p and h.
- Digital signature on e' and n. But NOT on s .It can be argued that s
has been signed since the digital signature has been applied on AVP1,
AVP3 and AVP4. But it isn't actually true. A can't decrypt s since
it's visible.

My conclusion is that, when assembling Diameter messages, the
participant must be very careful with the way in which it encrypts and
signs the AVPs (that was the purpose of issue 181) depending on the
parameter of the DSA. For instance, in your example, if the receiver
of the message is A and not P, the resulting message must look like:
    
--->>>  AVP1='P is clear', EnvelopedData-fnc(MIME(s,t,e),P) (*)
        AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A)
        AVP3='P is set',   e'
        AVP4='P is set',   n
        AVP5='P is clear', SignedData(T)
--->>>  AVP6='P is set',   s

(*) If no internal policy states that P also requests digital
signature on its encrypted AVPs.

It isn't important to note that, although there's no receiver of a
digital signature, there is actually a receiver of a Diameter message
secured with Diameter CMS Security.

Regards

  // M.A.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 14:41:31 +0100

Miguel,

I think it would be an error to start complicating the concept
of the DSA to include ideas about signing only being allowed
between nodes that share a DSA, and only for some AVPs and
only on Mondays and only if the sky's clear etc.. 

Signing is effectively independent of DSAs. Unnecessary signatures 
are no harm to anyone. Insisting on things not being signed when 
you don't care seems worse than useless to me.

> account that Diameter CMS Security employs widely DSAs. 

Nope. Signing with RSA doesn't ever require a concept of a 
receiver. End of story.

> The two

Irrelevant. If someone wants to do extra work signing then that's fine.
If someone needs a signature they insist on it.
There's no need to complicate things so lets not. 

(Or else reference the requjirement/use-case that shows that there is).

> and h. 

So A gets more stuff signed than he needs, big deal.

> The resulting message won't comply with the requests:

I think it is clearly wrong to suggest (as you seem to be doing) that
AVP 's' be sent both encrypted (AVP1) and in clear (AVP6). How could
that ever be a good idea?

> secured with Diameter CMS Security.

That sentence doesn't pass my parser:-)

Stephen.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 16:11:47 +0200

> So A gets more stuff signed than he needs, big deal.

I think that is the key point of this discussion. I've got no problem
with extra signatures. Just more stuff as you say. But if encryption
is involved isn't so easy.

> that ever be a good idea?

What I suggest is that if A wants encryption of e, p and h and digital
signature on e', n and s its irrelevant that e is actually present in
the message since it isn't visible for A. So that, if T want to fulfil
the requirements of P (the other participant of the DSA). If you don't
like my proposal about the message, what about this?

         AVP1='P is anything', EnvelopedData-fnc(MIME(s,t,e),P)
 --->>>  AVP2='P is set',      EnvelopedData-fnc(MIME(s,e,p,h),A)
         AVP3='P is set',      e'
         AVP4='P is set',      n
         AVP5='P is clear',    SignedData(T)

Anyway, AVP 's' has to be sent in a way that the requester (A, the
other participant of the DSA) can recover it. It means that it has to
be included twice because of the internal policy of T (that requires
an additional encryption for P). This is the end of story, isn't it? A
message encrypted for P is invisible for A.

My only purpose is pointing that a careful technique must be
implemented in a node when combining digital signature and encryption
(specially if several encryption receivers are involved). According to
this, I think that it's important to point that the message you're
using as example will depend on the previously established DSA.

> That sentence doesn't pass my parser:-)

May I suggest upgrading to a new version ;-))

Regards

  // M.A.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 16:14:08 +0200

> the requirements of P (the other participant of the DSA). If you don't
                                                          ^
                                                     it has to include
                                                    the AVP twoice

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 15:30:57 +0100

Miguel,

The original scenario in the example was:

The set of AVPs I described meet this requirement. 

In your mails you've added a new requirement "that s be sent 
to A", which I did not include. (Indeed by saying that s had to 
be encrypted for P, I was implicitly stating that "s not be 
visible to A".)

If your additional requirement were added to the list then

>          AVP5='P is clear',    SignedData(T)

The problem with it is that 'P is anything' is not allowed. P is
either set (in which case the AVP is input to signing) or is
clear (in which case it isn't).

That means that the set of AVPs below meets the combination of 
the original requirements and your new one ("that s be sent to A").

           AVP1='P is set',      EnvelopedData-fnc(MIME(s,t,e),P)
           AVP2='P is set',      EnvelopedData-fnc(MIME(s,e,p,h),A)
           AVP3='P is set',      e'
           AVP4='P is set',      n
           AVP5='P is clear',    SignedData(T)

Those AVPs can be sent to either P or A and will meet the 
requirements.

So, are you suggesting that I change the scenario to include the
additional requirement? If that's all: we're done, no problem,
I'll include it. (I guess it does show up a rule: don't send the
same AVP encrypted and in clear; which is probably worth stating
though it should be obvious:-)

If you're after something else, then I don't know what it is,
nor where the requirement is coming from.

Stephen.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 16:52:56 +0200

> The set of AVPs I described meet this requirement.

Yes, it did.

> be encrypted for P, I was implicitly stating that "s not be

Well, the new requirement only wanted to note that usually such
scenarios exist within a DSA. Just that.

> clear (in which case it isn't).

Right. I just wanted to say that, in a DSA between T and A, the actual
protection flag of AVP1 is irrelevant (if no protection status has
been stated for P).

> Those AVPs can be sent to either P or A and will meet the

Yes.

> I'll include it.

That's all. Just saying that when encrypting and signing, the
"receiver" (of the message, not of the digital signature, so that this
character doesn't play this movie) has to be taken into account.

> (I guess it does show up a rule: don't send the

Yes, it should have been obvious :-))

> nor where the requirement is coming from.

Nothing else.

Regards

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Sep 2001 16:01:17 +0100

Latest and greatest 6.1/6.2 text attached and we're done
(I hope:-)

Stephen.

Insert into section 6.0:

6.1  CMS-Signed-Data AVP

   

   

6.x Example encodings

   In order to clarify the contents of and the relationships between 
   CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following
   example of how these AVPs are calculated.
   
   First, some short-hand:

    The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n
    to meet the following: 
	AVPs s, t and e are to be encrypted for recipient P.
	AVPs e, p and h are to be encrypted for recipient A.
	AVPs s, and e' are to be signed by originator T.
	AVP  s is to be sent to recipient A.
	AVP  n needs neither signing nor encryption.

    Note that though there is no explicit requirement that AVP s be
    encrypted for A, since it will be encrypted for P, we also have
    to encrypt it for A. Implementations SHOULD NOT send the same
    AVP both encrypted and in clear.

    
    The result of this is that all AVPs excapt n are actually
    signed even though signing of t and e wasn't explicitly required. 
    However, this is no harm.

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Thu, 20 Sep 2001 17:09:49 +0200

> Latest and greatest 6.1/6.2 text attached and we're done

Perfect!!! :-)))

Regards

  // M.A.