headers
Andrew Regenscheid | 2 Jan 2008 16:54
Favicon

NIST IBE Workshop


NIST is holding a workshop on pairing-based cryptography and 
identity-based encryption in June of 2008.  I believe this is of 
interest to some of you given the S/MIME Working Group's efforts on 
the IBE internet drafts.  This workshop will focus on applications 
and will help us establish direction for future NIST work on 
pairing-based cryptography.  For more information, see the call for 
participation included below.

Thanks,
Andrew Regenscheid, NIST

CALL FOR PARTICIPATION

Applications of Pairing-Based Cryptography: Identity-Based Encryption 
and Beyond
June 3-4, 2008
NIST, Gaithersburg, MD

This workshop brings together academia, government and industry to 
explore innovative and practical applications of pairing-based 
cryptography.  Pairings have been used to create identity-based 
encryption schemes, but are also a useful tool for solving other 
cryptographic problems.  We hope to encourage the development of new 
security applications and communication between researchers, 
developers and users.  In addition to presentations, the workshop 
will facilitate panel discussions among invited experts and workshop 
participants.

CALL FOR PRESENTATIONS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman | 3 Jan 2008 03:58
Picon

Re: Comments on S/MIME v3.2


At 9:00 AM -0800 12/5/07, Turner, Sean P. wrote:
>At the meeting we had some comments on the S/MIME v3.2 specs 
>(draft-ietf-smime-3850bis-00.txt and 
>draft-ietf-smime-3851bis-00.txt):
>
>  1. Define SHOULD+, SHOULD-, and MUST-.
>  2. Update key size requirements and make sure you differentiate 
>between RSA/DSA and EC key sizes.
>  3. Check that there's no IPR wrt to ECDSA signed certificates and 
>using them with S/MIME.

Certicom has indeed asserted intellectual property rights for ECDSA. 
See <http://www.ietf.org/ietf/IPR/certicom-ipr-rfc-3446.pdf>. The 
last two sentences on the first page are particularly relevant.

As mentioned earlier on this thread, Certicom has also issued an IPR 
statement directly relating to S/MIME: 
<http://www.ietf.org/ietf/IPR/CERTICOM-SMIME>, and has also issued 
another relating directly to ECDSA: 
<http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA>.

Given these, particularly the most recent one pointing out the lack 
of licensing for being able to sign with ECDSA, it seems prudent to 
*not* mention ECDSA anywhere in draft-ietf-smime-3850bis-00.txt and 
draft-ietf-smime-3851bis-00.txt. If someone wants to give any 
specification for ECDSA (such as allocating OIDs or saying how to use 
ECDSA with S/MIME), they can write an individual submission and ask 
for it to become an Informational RFC.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maxim Masiutin | 3 Jan 2008 15:28
Favicon

missing algorithm parameters of signatureAlgorithm inside SignerInfo


I have discussed this issue with Russ Housley and have decided to bring it to the public concern. Russ have
proposed to deal depending on a particular algorithm. I, in contrast, think that this issue is abstract
and is not related  to any particular algorithm.

Could you please suggest how to deal with the missing algorithm parameters of signatureAlgorithm inside
SignerInfo type of SignedData?

I have found a message signed by an elliptic curve algorithm where signature algorithm parameters of
signatureAlgorithm inside SignerInfo where empty, and the elliptic curve algorithm didn’t work
without the parameters. If I take the parameters from SubjectPublicKeyAlgorithm of  signer’s
certificate (sid SignerIdentifier), then the signature verification was successful.

1.      Is it allowed to take algorithm parameters from signer’s certificate if they are omitted in
signatureAlgorithm of SignerInfo, or I should treat such a signature as invalid?
2.      If the parameters are both present and different, should I treat the signature as invalid or one
parameter should overwrite another?

Should we cover this case in a next revision of RFC3369?

Thank you in advance, and Happy New Year.
Permalink | Reply | 1 comment |
headers
Maxim Masiutin | 3 Jan 2008 15:33
Favicon

examples of S/MIME messages with timestamps


Could you please send me or publish to the list (or otherwise
published as internet-draft) several examples of S/MIME messages with
timestamps defined in 3126, i.e. signed messages with the Signature
Timestamp attribute (id-aa-signatureTimeStampToken). Thank you in
advance!
Permalink | Reply | 0 comments |
headers
Jim Schaad | 3 Jan 2008 21:35

RE: missing algorithm parameters of signatureAlgorithm inside SignerInfo


I have a number of questions that need to be answered before I can give you
a correct answer.

1.  What does the appropriate specification state is suppose to be present?
RFC3278 states that the correct SignatureAlgorithm parameters are NULL for
ecdsa-with-SHA1.

2.  Are you looking for the Public Key parameters or the Signature Algorithm
parameters.  Please note that these are different and need to be kept
separately. 

Public key parameter MUST be obtained from the certificate (for certificate
based systems).
Signature algorithm parameters MUST be obtained from the
SignerInfo.signatureAlgorithm

jim

> -----Original Message-----
> From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-
> smime <at> mail.imc.org] On Behalf Of Maxim Masiutin
> Sent: Thursday, January 03, 2008 6:28 AM
> To: ietf-smime <at> imc.org
> Subject: missing algorithm parameters of signatureAlgorithm inside
> SignerInfo
> 
> 
> I have discussed this issue with Russ Housley and have decided to bring
> it to the public concern. Russ have proposed to deal depending on a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Cheng | 10 Jan 2008 15:59
Picon

RE: I-D Action:draft-gutmann-cms-hmac-enc-00.txt


Hi Peter,

On the definition of Auth-Enveloped for hash-based MAC or other MACs, I have several comments:

1. In section 3, change KEK( master_secret ) || HMAC( encrypt( data ) ) to KEK( master_secret ) || encrypt(
data )  || MAC( encrypt( data ) ). There is no description to state that HMAC's output includes its input.

2. On the generation of CEK-K and HMAC-K, I don't see strong case that the method describe in the draft should
be adopted. One call to a KDF to generate both keys from a master key is much simpler and this method is also
used in many other standards such ISO 18033-2.

3. One may want to use other MAC methods instead of HMAC in considering the security of hash functions.

I'd like to suggest the following generic definition following ISO18033-2's DEM definition.

Following the CCMP ang GCMP definitions for Auth-Enveloped-Data:

ContentEncryptionAlgorithmIdentifier ALGORITHM ::={
 { OID id-aes128-CCM PARAMS CCMParameters } |
 { OID id-aes128-GCM PARAMS GCMParameters } |
 { OID id-data-encapsulation PARMS DEMParams } |
 ... -- Expect additional algorithms --
}

DEMParams ::= SEQUENCE {
 keyDerivationFunction KeyDerivationFunction,
 encAlgo      SymmetricCipher,
 macAlgo      MacAlgorithm }
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman | 10 Jan 2008 23:36

Seeking comments on draft-ietf-smime-new-asn1-00.txt and draft-ietf-pkix-new-asn1-00.txt


I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?

--Paul

Greetings again. Jim Schaad and I have produced these two documents 
as WG items, based on the discussion last month in Vancouver. They 
include corrections to our original personal drafts, and some new 
modules. We actively seek comments on these two drafts.

One of the biggest questions is, which RFCs should and should not be 
in the draft? This breaks down into some sub-questions:

- Should we include only standards-track RFCs? What about 
Informational RFCs that came from a WG or were heavily vetted by a WG?

- Should we include RFCs that could benefit from new object classes 
but do not actually need to be updated in order to comply with the 
new ASN.1? Asked another way, should a module that did not contain an 
ANY be included?

- Should we create a module that is just the OIDs assigned across all 
the other modules? Should we create two (one for S/MIME, one for 
PKIX), or just a single OIDs module?

Again, we look forward to the discussion.

--Paul Hoffman, Director
--VPN Consortium
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephen Kent | 11 Jan 2008 00:00
Picon

Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and draft-ietf-pkix-new-asn1-00.txt


At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>
>--Paul

you just did send it :-).

Steve
Permalink | Reply | 2 comments |
headers
Paul Hoffman | 11 Jan 2008 00:26

Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and draft-ietf-pkix-new-asn1-00.txt


At 6:00 PM -0500 1/10/08, Stephen Kent wrote:
>At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>>
>>--Paul
>
>you just did send it :-).

Well, now everyone can tell that I got Jim's approval before sending it off...

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 12 Jan 2008 09:17
Picon
Picon
Picon
Favicon

Public-key distribution via HTTP

[CC'd to various lists who might be interested]

Someone recently asked on a security list whether there was a simple way of
putting your public key on a web server based on "a set of goals, hopefully
sufficiently unambitious, so one knows what one wants to do very precisely.
Given those, I suspect a decent spec replacing hundreds of pages of currently
'standard' and useless mechanism could be crafted in about 10 to 30 pages)".
My response was "You've just described RFC 4387 :-)".  The list reaction was
that no-one had known until then that this document even existed, so I'm
posting this to a couple of lists where people might find it useful.

Don't be mislead by the title (http://www.ietf.org/rfc/rfc4387.txt), it was
published under the auspices of PKIX but it's really "a simple, fairly
universal means of publishing your public key via HTTP".  The CACert folks
have set up a Wiki page to cover implementation info, feedback, and comments:
http://wiki.cacert.org/wiki/RFC4387.

(Please, no religious arguments over this: If you think it's useful, implement
it.  If not, ignore it).

Peter.
Permalink | Reply | 2 comments |

Gmane