RE: Another Potential Work Item

"Tony Capel" <capel@comgate.com> Fri, 08 May 2009 18:47 UTC

From: Tony Capel <capel@comgate.com>
To: ietf-smime@imc.org
Cc: 'Sean Turner' <turners@ieca.com>
Subject: RE: Another Potential Work Item
Date: Fri, 08 May 2009 14:35:31 -0400
Message-ID: <3B900B8944EA4BA9A9961812E9C02EC6@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcnOks5kjoAQn1XzTEmuDnDmrqBTiwBeMQPw
In-Reply-To: <4A020131.6010403@ieca.com>
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk

Yes,
it would be useful to have a comprehensive reference to these attributes.
(It would be nice in the future to use a registry for this, to allow timely
updates!)

Tony

| -----Original Message-----
| From: owner-ietf-smime@mail.imc.org 
| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Sean Turner
| Sent: May 6, 2009 5:29 PM
| To: ietf-smime@imc.org
| Subject: Another Potential Work Item
| 
| 
| 
| I have had a new draft posted as an individual draft.  I 
| would like the working group to consider adopting the draft 
| as a WG item.
| 
| http://www.ietf.org/internet-drafts/draft-turner-additional-sm
imecaps-00.txt 

provides a list of SMIME capabilities.  Some are already contained in 
RFCs and some are not.  What I'm trying to figure out is whether we 
should relax the requirements in S/MIME MSG (all the way back to RFC 
2311, 2633, 3851, and 3851bis) that say "In the event that there are no 
differentiating parameters for a particular OID, the parameters MUST be 
omitted, and MUST NOT be encoded as NULL."  I think many implementations 
and a few RFCs didn't follow this requirement, e.g., ECDSA, ECDH, ECMQV 
in RFC 3278 and RSAES-OAEP in RFC 3560.  We'd also like to lock down 
what implementations do for RSA with *.

spt

Another Potential Work Item Sean Turner
RE: Another Potential Work Item Tony Capel