Re: DSA & ASN.1

hello,

Can anyone let me know the ASN.1 Specification 
for Digital Signature Algorithm.

Thanks,

Chandar 

Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct

W2K fakes 128-bit crypto or not?

Denis,
no news on this alarming news of yours?

Anders

-----Original Message-----
From: denis bider <denis.bider <at> globera.com>
To: 'Anders Rundgren' <anders.rundgren <at> jaybis.com>; ietf-pkix <at> imc.org <ietf-pkix <at> imc.org>
Date: Saturday, June 17, 2000 15:43
Subject: Off-topic: crypto crippling

>[I would have posted this to the sci.crypt newsgroup, but I dislike doing
>that for several reasons - among them, slow message propagation, spam and
>last but not the least, I do not have Usenet configured and it takes a while
>to find a server that carries sci.crypt. Does anyone know of a regular
>mailing list equivalent to the sci.crypt newsgroup?]
>
>Actually,
>
>I have heard a rumour that the '128-bit encryption' that Microsoft is
>shipping with Windows 2000 has actually been tweaked in such a way that it
>is only 128-bit when observed by a non-clued-in person, but is rather 40-bit
>for the people who know how it has been designed.
>
>In effect, rumour therefore has it that 88 bits out of the 128 are set in
>such a way that it is extremely easy to find them for someone who knows how.
>The French are supposed to have found this out, and they are supposed to
>have been a little bit upset because of this fact.
>
>I am not sure how much of this is actually the truth. The person I received

RE: W2K fakes 128-bit crypto or not?

Hello Anders,

I have received no responses by members of this group.

I guess if the rumour had any merit then at least someone ought to have
heard? Or maybe not necessarily: just the other day I found sound-looking
information about how id Software has built a backdoor (yes, a back door,
kind of like Back Orifice) into its Quake product. Yes, Quake, the game.

It's interesting how these things don't get known or talked about - for
instance, the general population seems never to have heard about ECHELON.
Seems that, when it comes to striking news like this, people who haven't
seen the facts themselves are afraid of spreading the word, fearing that if
the rumour is proven wrong, they will be considered naive dummies without
credibility.

I have since subscribed to sci.crypt (hurray), so I'll run this W2K rumour
by them, too. I'll report if there is any response.

Regards,

denis

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren <at> telia.com]
Sent: 3. julij 2000 01:40
To: denis-at-globera <at> denisbider.com; ietf-pkix <at> imc.org
Subject: W2K fakes 128-bit crypto or not?

Denis,

RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

Stephen,
> 
> I may have lost track of the counter argument here.  Why would one 
> not want to have a TSA do the best possible job when it comes to 
> ensuring syntactic consistency re its inputs?

A few of us are being concerned that forcing the TSA to 'know' the hash oid
and to perform the sanity check is an unnecessary requirement, causing more
evil than good. 
Instead of reiterrating our position, I've attached a few messages from the
thread which summarize the views.

Regards
Michael

From: Stephen, > > I may have lost track of the counter argument here. Why would one > not want to have a TSA do the best possible job when it comes to > ensuring syntactic consistency re its inputs? A few of us are being concerned that forcing the TSA to 'know' the hash oid and to perform the sanity check is an unnecessary requirement, causing more evil than good. Instead of reiterrating our position, I've attached a few messages from the (Continue reading)

Senate Bill 671

Re: certificate chain validation(policy extension)

 Thank you very much for the reply.

 I agree with you.  It depends on the policy constraints extension.

 However, I think that the process of (e)(f)  is to keep the certificate policy's
consistency in certificate chain. If the SkipCerts is greater than zero, and the policy
extension is null, how can we  explain it(in this case the Cert chain will be valid)? 

 Thanks in advance.  

KwonSung Chung wrote:
> 
> I think it is depend on policy constraints extension.
> 
> If requireExplicitPolicy sub-field of the Root certificate
> has 0 as value of SkipCerts, the certificate chain is invalid because
> the policy checking about CA certificate  must be processed.
> 
> But, in the case of positive integer(greater then  zero), the certificate chain is
> valid ( if other extension is valid).
> 
> ------------------
> KwonSung Chung
> KISA
> kschung <at> kisa.or.kr
> ------------------
> 
> Kong QiuYan wrote:
> 
> > Suppose I have a certificate chain consisting of a Root, a CA and a User
> > certificate.
> >
> > The policy extension in the Root certificate contains one oid of 1.1.1(critical)
> > The policy extension in the CA certificate does not exist.
> > The policy extension in the User certificate contains one oid of 1.1.1(critical)
> >
> > Assuming all other data is valid, is this a valid certificate chain?
> >
> > It appears to me that the algorithm defined in RFC2459 would determine that
> > this certificate path is valid.
> >
> > -----------
> > RFC2459 6.1 says:
> >
> >       (e)  Verify that policy information is consistent with the
> >       acceptable policy set:
> >
> >          (1) if the certificate policies extension is marked critical,
> >          the intersection of the policies extension and the acceptable
> >          policy set shall be non-null;
> >
> >          (2) the acceptable policy set is assigned the resulting
> >          intersection as its new value.
> >
> >       (g) Verify that the intersection of the acceptable policy set and
> >       the initial policy set is non-null.
> > ---------
> >
> > Personally, I think that all of the certificates in a valid path must have
> > policy extension(critical or non-critical). Am I wrong?
> >
> > QiuYan Kong,
> > Fujitsu Ltd

--

-- 
-------------------------------------------------
Kong QiuYan
FUJITSU LIMITED
EMail: kongqy <at> ec.cs.fujitsu.co.jp
  TEL: +81-45-473-3707

roaming credentials (sacred)

Hi All,

I put up a slide in Adelaide about roaming credentials and it 
looks like we're on for a BOF in Pittsburgh (date TBD). The
strawman charter/BOF description is attached. So, if you're 
interested then subscribe to the list and let's see how much
progress we can make prior to Pittsburgh.

Paul Hoffman has kindly agreed to host the mailing list which 
he'll open for postings in a day or two, as soon as subscribing 
is seen to be working without problems, (but you can subscribe 
right now). Paul's also hosting the web site at:

           http://www.imc.org/ietf-sacred

If you have any questions in the meantime, feel free to 
mail Magnus and/or me directly.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell <at> baltimore.ie
Ireland                             http://www.baltimore.com

Strawman charter for Securely Available Credentials (sacred) WG:
================================================================

Working Group name:      Securely Available Credentials (sacred)

Chairs (suggested):      Stephen Farrell, Baltimore Technologies
                         <stephen.farrell <at> baltimore.ie>, and
                         Magnus Nystrom, RSA Security Inc.
                         <magnus <at> rsasecurity.com> 

Area:                    Security

Area Directors:          Jeffrey Schiller <jis <at> mit.edu>
                         Marcus Leech <mleech <at> nortelnetworks.com>

Resp. Area Director:     TBD

Mailing list:            ietf-sacred <at> imc.org

Web Site:                http://www.imc.org/ietf-sacred/

Descr. of WG:

A nice feature of smart-card based PKIs, in addition to the security
offered by the cards themselves, is the "free-seating solution," or
the portability of user's credentials. In order to provide a similar
solution or service to environments where security is based on pure
software implementations or so-called "soft tokens" (a.k.a. "virtual
smart cards," software files containing information normally stored
on smart cards) some kind of credential store from which users can
download their soft-tokens, using some specified protocol is
required. This protocol will provide mobility for credentials.

Such a protocol and specified data format might also allow an
individual user to have the same set of credentials on, e.g., her
mobile phone as in her desktop. Adding an upload protocol to the
solution means that it in principle would be possible to always have
the credential store up-to-date.

Even in some cases where real smart cards are used, there may
be some benefit to using such a protocol - e.g. when a new card
is received, but "old" credentials should be used. If the cards
offered the appropriate install and delete interfaces, then the
credentials could be (securely) moved between cards.

Many desktop applications also require mobility of credentials, for 
example to  support some "kiosk" style operation, when a user 
upgrades a PC, or when "hot-desking". It is sometimes required to 
integrate such credential mobility with single-sign-on solutions. A 
protocol that could be used in the smart card case, can also be 
used to solve this case.

Finally, some applications may benefit from the ability to migrate
credentials from a device to a smart card, in particular where
the smart card using device has limited user interface capabililies,
e.g. a mobile phone.

Security is at a premium for this working group; only authorized
entities should be allowed to download credentials, credentials must
be protected against eavesdropping and cut & paste attacks; attackers
must not be able to succesfully replace an entities credentials at a
credential serer; etc.

Availability is also at a premium, a credential server must
be reachable from many different types of client with different
characteristics in terms of processing power, storage and
network connectivity.

The purpose of this working group is therefore to gather 
requirements for a solution beneficial to the Internet 
community, establish a framework for such a solution, and to
develop or adopt the required protocols and credential formats. 

Goals & Milestone:       

(The timeline assumes that the WG is approved just after 
Pittsburgh.)

Oct 00  Submit first draft of Requirements document

Nov 00  Submit first draft of Frameworks document

Dec 00  Submit second draft of Requirements document
        Submit second draft of Frameworks document
        Submit first draft of Protocol document (incl. PDU syntax)

Mar 01  Requirements document to Informational RFC
        Frameworks document to Informational RFC
        Submit second draft of Protocol document

Jun 01  Protocol document to Proposed Standard

Jul 01  WG recharters if appropriate

Outline BOF Agenda:

- agenda bashing
- scene setting (some problems that might be solved)
- HTTP/SASL strawman
- <other proposals>
- WG charter discussion

RFC 2459 and internationalized domain names

Greetings again. There is active work in the IETF to allow non-ASCII 
characters in doamin names. This is being considered in the IDN 
Working Group (see 
<http://www.ietf.org/html.charters/idn-charter.html> for the WG 
charter). There is a strong desire for these names in many parts of 
the world.

If the wire format for the new domain names includes non-ASCII 
characters (which seems likely to me), then we probably should change 
2459 to handle these new names. Fortunately, son-of-2459 is still not 
finished.

Please note that:
- The IDN WG may not come up with a protocol
- The protocol may be ASCII-only, using an encoding scheme that maps 
to the current rules for domain names
- If there is a binary protocol, it is likely (but not definitely) 
going to be UTF-8

Given that, it might be wise of us to either change how domain names 
are represented 2459 or to put warnings into the text about this  in 
son-of-2459. It is likely that son-of-2459 will be finished well 
before the IDN WG is finished.

Oh, and if the IDN WG creates a binary protocol, there will be a 
strong demand for changes to the email protocols to handle binary 
domain names in headers. There will also be a strong demand for 
binary on the left-hand side of the addr-spec. We may wan to consider 
these as well.

Thoughts?

--Paul Hoffman, Director
--Internet Mail Consortium

kein Betreff

unsubscribe

RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt : SIA

Some time ago I had asked about the status of the 
Subject information Access extension mentioned in the actual
time stamping draft as being or to be defined in son of RFC2459.

It would be nice to hear some more details about that from
let's say one of the editors of the documents mentioned.

Thanks in advance
Peter Sylvester