> > "Is it possible to extend the expiry of this certificate
> > without changing any other fields in the certificate?"
> >
> > to which it seems that the answer is
> >
> > "Yes",
>
> How could the answer be anything other than yes?
All too easily. Because as you ourself point out, such a change
That line means "if benc still points at something, free it". The problem
is - more likely than not, somebody has already freed benc, but did not set
benc to zero (or NULL). As a result, this check (line 640) says "benc is not
zero, so it must be pointing at something that must be freed, so invoke
> For both the responses I got, it looks like the server need
> to access the information (whether identity or attribute or
> whatever) present in the certificate and use that to decide
> the permissions for the peer that represented this certificate.
> Is my understanding correct?
Partially so
> Well, the Subject Distinguished Name should have the
> Organization...
Can you envision long-lived certs issued by gov't - like passports? In that
case, Organization would not have the same semantics. But this is less
relevant for our discussion.
> ...but I strongly disagree with you if you th
> > ... is it necessary to
> > issue ONE certificate to EACH individual.
>
> Yes. The problem of granting access based on membership in a
> group is an authorization problem.
Correct.
> This doesn't have
> anything to do with certificates -- permissions and roles
> change independently of
> > There are security paradigms such as SSH where you use "leap of
> > faith": strictly you haven't authenticated the remote end, but you
> > "know" that your peer is the other box next to you, you
> > verified its PK fingerprint visually, so you approve ("authorize")
> > that peer from now on.
Traditionally the term "self-signed" applied to certificates that are NOT
signed by anybody but the owner of the given key pair. With all the relevant
security implications.
What is the purpose of checking for "self-signed cert"? To see if only the
owner signed that key? Of to see that key owner A
d, 30
> 28911 Leganés (Madrid/Spain)
> Tel: (+34) 91-624-8817, Fax: -8749
> Web: www.it.uc3m.es/dds
> web: http://www.it.uc3m.es/pervasive
> Mail: dds[at].it.uc3m.es
> Skype: dds.it.uc3m.es
>
>
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL P
t: Re: Attribute Certificate with OpenSSL?
>
> On 9/14/06, Mouse <[EMAIL PROTECTED]> wrote:
> > Did anybody use OpenSSL successfully for creating and processing
> > Attribute Certificates?
>
> very much .. chek dis link.. http://openpmi.sourceforge.net/
>
&
Did anybody use OpenSSL successfully for creating and processing Attribute
Certificates?
Is there any helpful HOWTO or TFM?
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
There is one more problem with attributes and official CA's. If you are your
own CA, it makes a big difference (less trust around in the world - but you
can enforce any attribute verification policy that you choose yo).
Atttributes are added at the time of certification (good - so they can't be
ma
his helps.
>
> Regards,
>
> Dmitrij
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Mouse
> > Sent: Friday, August 04, 2006 5:10 PM
> > To: openssl-users@openssl.org
> > Subjec
It doesn't makes much sense to add attributes to certs if values of those
attributes can't be verified. Attribute Certificate seems the right way to
go (thanks, Vijay!).
The question is - do our "mainstream" CA's (such as VeriSign, etc.) support
Attribute Certificate?
Tnx!
> -Original Mess
PEM = Privacy-Enhanced Mail.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bo Xie
> Sent: Monday, July 31, 2006 20:08
> To: openssl-users@openssl.org
> Subject: What does "PEM" mean?
>
> I know openSSL supports .pem format. But what does "PEM" m
> The security work in SNMPv3 is old and outdated and years
> behind current practice. Some of that is understandable, but
> but even back then we knew enough to know that raw UDP is
> almost architecturally flawed.
Not quite on the list topic - but if you were aware of the constraints
placed
> > openSSL 0.9.8 comes with support for DTLS, which is TLS over UDP.
>
> Another point for the original poster to keep in mind is that
> SSL/TLS can require multiple read/writes for a single
> application-level packet exchange.
SA establishment cost...
> This isn't always obvious to folks st
16 matches
Mail list logo
