headers
Jim Schaad | 3 Aug 2007 22:49

RE: Algorithm Class Data


Dave,

What I am looking at doing the associations for is the data structures not
the data themselves.  Thus for example, I have several different tables in
my system that say what the different structures are that are associated
with each algorithm OID.  The ability to encode this in the ASN.1 module,
and thus potentially to have the data transferred to my program, seems to me
to be a good thing.

Jim

> -----Original Message-----
> From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-
> smime <at> mail.imc.org] On Behalf Of Kemp, David P.
> Sent: Monday, July 30, 2007 9:10 PM
> To: ietf-smime <at> imc.org
> Subject: RE: Algorithm Class Data
> 
> 
> Jim,
> 
> What is the purpose of "associating" information in an ASN.1 module?
> Since ASN.1 describes the syntax of (for example) a signature as
> transmitted between systems (OID, Parameters, and Signature Value),
> I'm not sure what a compiler would do with other data associated
> with a signature.  The public key used to validate a signature is
> not contained in the same data object as the signature value itself
> (certificate vs. signed object), a private key might not appear
> in any ASN.1 module at all, and the data over which a signature is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Schaad | 3 Aug 2007 22:49

RE: Algorithm Class Data


Russ,

Here would be an example.   (Please note - this is conceptual ASN.1 not real
ASN.1)

MY-ALG-CLASS ::= CLASS {
     &id             OBJECT IDENTIFIER,
     &privKeyType OPTIONAL,
     &pubKeyType,
     &pubKeyParams DEFAULT NULL,
     &sigStructure,
     &sigParams)

alg-DSS MY-ALG-CLASS { id-dss, INTEGER, INTEGER, dss-params, DSS-SIG, NULL }

All of the data is not associated together in META-DATA - this does not
affect what goes out over the wires, however the information could
potentially be used in the encode/decoder with some re-writes of the data
such as

SIGNED(ToBeSigned) ::= {
   toBeSigned    ToBeSigned
   algorithm    SEQUENCE {
       sigId   MY-ALG-CLASS.&id({SigAlgs}),
       params  MY-ALG-CLASS.&sigParams ({SigAlgs}{ <at> sigId}) OPTIONAL,
   },
   Signature BIT STRING (CONTAINING
MY-ALG-CLASS.&sigStructure({SigAlgs}{ <at> algorithm.sigID}))
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Aug 2007 20:15
Picon
Favicon

I-D ACTION:draft-ietf-smime-cades-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: CMS Advanced Electronic Signatures (CAdES)
	Author(s)	: J. Ross, et al.
	Filename	: draft-ietf-smime-cades-03.txt
	Pages		: 132
	Date		: 2007-8-6
	
This document defines the format of an electronic signature that can
   remain valid over long periods.  This includes evidence as to its
   validity even if the signer or verifying party later attempts to deny
   (i.e., repudiates the validity of the signature). 

   The format can be considered as an extension to RFC 3852 [4] and 
   RFC 2634 [5], where, when appropriate additional signed and 
   unsigned attributes have been defined.  

   The contents of this Informational RFC amounts to a 
   transposition of the ETSI TS 101 733 V.1.6.3 (CMS Advanced 
   Electronic Signatures - CAdES) [TS101733] and is technically 
   equivalent to it.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Turner, Sean P. | 6 Aug 2007 22:24

WG LC: draft-ietf-smime-cades-03.txt


This message initiates an SMIME Working Group Last Call on the document:

 Title     : CMS Advanced Electronic Signatures (CAdES)
 Author(s) : J. Ross, et al.
 Filename  : draft-ietf-smime-cades-03.txt
 Pages     : 132
 Date      : 2007-8-6

This document obsoletes RFC 3126.	

This document defines the format of an electronic signature that can remain
valid over long periods.  This includes evidence as to its validity even if
the signer or verifying party later attempts to deny (i.e., repudiates the
validity of the signature). 

The format can be considered as an extension to RFC 3852 [4] and RFC 2634
[5], where, when appropriate additional signed and unsigned attributes have
been defined.  

The contents of this Informational RFC amounts to a transposition of the
ETSI TS 101 733 V.1.6.3 (CMS Advanced Electronic Signatures - CAdES)
[TS101733] and is technically equivalent to it.

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-ietf-smime-cades-03.txt

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as an
Informational RFC.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Blake Ramsdell | 8 Aug 2007 02:20
Favicon

Re: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt


Russ Housley wrote:
> Draft -04 of this document came out, but many of my concerns were not 
> addressed.

Authors, where are we on this?

Blake
--

-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
Permalink | Reply | 1 comment |
headers
Luther Martin | 8 Aug 2007 02:32

RE: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt


Another version will be in later this week. 

> -----Original Message-----
> From: Blake Ramsdell [mailto:blake <at> sendmail.com]
> Sent: Tuesday, August 07, 2007 5:21 PM
> To: Luther Martin; Mark Schertler
> Cc: Russ Housley; ietf-smime <at> imc.org; tim.polk <at> nist.gov
> Subject: Re: Late WG Last Call Comments:
draft-ietf-smime-bfibecms-03.txt
> 
> Russ Housley wrote:
> > Draft -04 of this document came out, but many of my concerns were
not
> > addressed.
> 
> Authors, where are we on this?
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
Permalink | Reply | 0 comments |
headers
Russ Housley | 11 Aug 2007 17:00

Re: Algorithm Class Data


Jim & Paul:

>>I do not see how these impact the things that go on the wire.
>
>That's exactly the point.
>
>>Maybe I have not thought about it enough, but an example would help 
>>me understand your proposal better.
>
>The idea is to have more programmatic logic in the ASN.1 module 
>itself, I believe. Right now, we have text in the RFC, comments in 
>the ASN.1 module, and the code-reflecting parts of the module. 
>Moving some of the first two into the latter might make 
>interoperability more likely.

That is not useful unless other development tools draw the line in 
the same place, right?

Russ
Permalink | Reply | 6 comments |
headers
Internet-Drafts | 13 Aug 2007 20:15
Picon
Favicon

I-D ACTION:draft-ietf-smime-bfibecms-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the
Cryptographic Message Syntax (CMS)
	Author(s)	: L. Martin, M. Schertler
	Filename	: draft-ietf-smime-bfibecms-05.txt
	Pages		: 15
	Date		: 2007-8-13
	
This document describes the conventions for using the Boneh-Franklin 
        (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 
        the Cryptographic Message Syntax (CMS) to encrypt content-encryption 
        keys. Object identifiers and the convention for encoding a 
        recipient's identity are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-bfibecms-05.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 13 Aug 2007 21:16

Re: Late WG Last Call Comments: draft-ietf-smime-bfibecms-03.txt


Draft -05 was just posted.

>>I was not able to review this document before WG Last Call 
>>ended.  However, I do have some comments.  Please treat them as 
>>late WG Last Call comment or early IETF Last Call comments.
>>
>> > http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
>>
>>1) Section 2 defines EmailIdentitySchema as a UTF8String.  The text says:
>>
>>       E-mail addresses that contain non-ASCII
>>       characters MUST be encoded using punycode [RFC3492].
>>
>>Therefore, the result of the encoding should always be ASCII.  Why 
>>is an UTF8 String needed?
>
>I understand that the authors are receiving conflicting advice from 
>Jim Schaad and myself.  I have sent email to Jim to try and 
>understand his point of view, but Jim has not responded.  The text 
>was updated to use UTF8, without requiring punycode.  I think this 
>was the wrong way to resolve this one.  I would prefer to retain the 
>use of punycode and carry the email address in an IA5 string.  The 
>reason that I prefer this solution is that traditional character 
>comparison routines can be used.
>
>Since Jim is not engaging in the conversation, I would like to know 
>what others think.

I wish others would speak up on this point.  I think this is an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 13 Aug 2007 21:35

UTF8 vs. Punycode


This issue was raised by my review of
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt

However, I think that the issue goes beyond this document.  The 
decision made here ought to set a precedent.

My original comment was:

>1) Section 2 defines EmailIdentitySchema as a UTF8String.  The text says:
>
>       E-mail addresses that contain non-ASCII
>       characters MUST be encoded using punycode [RFC3492].
>
>Therefore, the result of the encoding should always be ASCII.  Why 
>is an UTF8 String needed?

I think that the use of punycode in an IA5String was the correct 
approach.  This approach uses the ToASCII algorithm to generate an 
ASCII string from the Unicode string.  The punycode can then be 
operated on using the usual subroutines to handle copy, compare, and such.

The alternative is to use UTF8, which cannot be operated on using the 
usual subroutines to handle copy, compare, and such.

I understand that the authors are receiving conflicting advice on 
this point from Jim Schaad and myself.  I have sent email to Jim to 
try and understand his point of view, but Jim has not responded.  The 
text in the most revision of this document was updated to use UTF8, 
without requiring punycode.  I think this was the wrong way to
(Continue reading)

Permalink | Reply | 503 comments |

Gmane