Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14

From: Peter Sylvester <[email-masked]>
Date: Wed, 01 Feb 2006 15:50:32 +0100

The origin of that point was handled end of 2001 for about 6 months. 
There were many
contributions, and you were actively involved.

I rediscovered that it was me to confirm the requirement for a textual
field following a debate with Denis who interpreted my request for an 
'identifier' as such
whilst I was thinking somthing like expressed in a messagez from Tom:

     Denis, Peter:

     I have one question about this proposal.  Is the object to be placed
into the response a transaction identifier or the RP's identifier?  If it's
the RP's identifier, IMO it should be called something like "requestor's
claimed identity" and it should not be permitted to be altered by the
server, although it might be permitted to be dropped.

           Tom Gindin

And I had this:

I have proposed in a different mail to Russ:
 The protocol MUST provide a means to allow a client and a server
 to indicate the participating entities.
I correct '... to indicate the identities of the entities participating in
the transction'.
and one may add "(depending on policy or application context)".

The discussion was stopped by Steve somehow

Peter;  Steve Kent said a few days ago:

" We agreed  to allow competing protocol submissions which would be 
evaluated  against the requirements. "

This does not mean IMO, that it is forbidden to have more features
than those specified in the requirement doc.
Peter,

> Denis,
>
> Are you asking for a requirement to be included in the
> text that indicates:
>
> " A protocol that implements the requirements of this document
>   MUST NOT, never ever, implement other features, even optional ones. "

I do not think that we need any sentence. Now, if we really needed one, 
here
is a proposal:

The basic protocol SHOULD NOT support any additional requirement besides 
the
requirements listed in this document. Any additional feature not listed
SHOULD only be supported using extension fields.

Denis

------
The discussion concerning entity identifier continued later during SCVP,
do you need another reminder?

----

>
> I do not recall the origins at this point.  Your requirements is 
> clearly already met by the existing protocol elements.  We need to 
> deal with the protocol requirements as documented, or we need to 
> changes them, which is more work at this point.

No, it doesn't.

The request and response contain inconsistent specifications for 
requestorName and responderName.

In the request, requestorName is a GeneralName, whilst in the response 
it is GeneralNames,
The request should also be requestorNames.

And responderName should be similar. It was in verion 18 or so that the 
response already
had a responderName, which was silently removed.

The responderName in the request does not indicate you should sign 
(well, IMO it should giove a hint
of who should perform). And a comparable field in the response is 
missing identifying the
responders.

The response does not identify the entity that has created the response. 
We had this discussion
about whether an identity can be derived from an authentication means 
before.

Peter

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Russ Housley <[email-masked]>
Date: Thu, 02 Feb 2006 00:07:40 -0500

Peter:

I recall your request for requester and responder identities.  I do 
not recall the origin of the text field requirement.

Russ

---

From: Michael Ströder <[email-masked]>
Date: Wed, 01 Feb 2006 19:03:13 +0100

Russ Housley wrote:
> 
> I would suggest:
>     UTF8String (SIZE (1..256))

+1

Avoid OCTET STRING for textual data (character strings) whenever possible.

Ciao, Michael.

> 
> At 10:28 PM 1/30/2006, Tom Gindin wrote:
> 
>>         Russ:
>>
>>         Although several values of GeneralName are (IA5) text strings,
>> none of them are free-form ones, so they don't really fit this
>> requirement.  The solution given in your note seems better.  I do have
>> one
>> request for clarification, though.  Is the length limit 256 Unicode
>> characters, or 256 octets?  The text suggests Unicode characters, but it
>> isn't absolutely clear.  Given that the string is simply copied, a length
>> limit in octets might make more sense.  Indeed, in view of the fact that
>> the string's internal structure is not important to the server, it might
>> be wiser to encode it as an OCTET STRING.
>>
>>                 Tom Gindin
>>