[Help-gnutls] Re: Really I can not understand nothing of SSL...

[Fran]

I am not a hacker of gnutls, I'm not a hacker of unix, I'm not a hacker
of C

What need a stupid programmer like me here?
It's easy:
- Extract the visible parameters, like serial, CN, Issuer, etc... (real
world)
Why?
Common name and serial identify a certificate ->> Identify an user.

Which is the problem?, if I make a struct to store visible parameters, I
do not known sizeof(serial). Could be store in hexadecimal number, but
hexadecimal number is very difficult to manage. (The limit is in the
sky)

> gnutls_x509_crt_get_serial (cert, serial, &serial_size) >= 0)

Isn't hexadecimal, decimal.

1,844674407 E19 /* puuufff */
X509_useful.serial = strtoll (raw_to_string (serial, serial_size), NULL,
10); /* bug, bug,bug, if expected size > 2^64 */
> 
>Why certtool request for a int number for serial?, if I think that
>should be >= unsigned long long (64 bit):
>  Hello.  'Unsigned long long' is a non-standard C extension, is it
not?
?
>  We want the code to work with standard compilers.
Yes


"int" can be -1,..., tralala, tralala,0,...,
I think that from "int" you can not use a number larger that 2^32 (u
int). how to extract number larger than "int"?

> >>  int size, serial, client;
> >> 
> >> serial = get_serial();
> >> 
> >> "int" get_serial(void)
> >> {
> >>     if (batch) {
> >>         if (cfg.serial < 0)
> >>             return 0;
> >>         return cfg.serial;
> >>     } else {
> >>         return
> >>             read_int("Enter the certificate's serial number
> (decimal): ");
> >>     }
> >> }
> 
> I believe the proper solution is to make get_serial
> support a hex string format too (perhaps recognized through a  >prefix
of '0x'?). 

Ok, get_serial should support a hex string or decimal bigger number.

>If this is important for you, please propose a patch for
> inclusion.

Time ago I sent you some ideas, about other things >> trash.

> get_serial return a hex string instead.
> Then we won't have arbitrary limits, be them 32, 64 or 128 bits.
> Fixing that look rather simple; patches welcome.

I can not help you, sorry.


who have certificates?
>How  much time a certificate could be valid, 1 year,two year,
>100year :)
>How much users can be CA certificate  ¿9E9?, 0ne certificate per hour
>for each user:

>8760 hours per year
>7.884E13 crt per year

>2^64 / 7.884E13 = 233976.9669 years. 
>In my opinion when serial >= limit should be reset to another CA
>name .(my opinion >> trash).
>Support Verisig.n enterprise ....... years?


The problem is easy "manage and store certificate information"  (user
level). Here is the problem:
-compatibility (all systems)
or
-efficiency

How to solve the problem? Put a config  flag, verify all times if serial
< 64 bits, transform every time to hexadecimal number, or functions
should return hexadecimal?


Thanks, for your time; sorry for my English.


On Lun, 2005-08-08 at 15:41 +0200, Simon Josefsson wrote:
> Andrew Suffield <asuffield at suffields.me.uk> writes:
> 
> > On Mon, Aug 08, 2005 at 02:34:04PM +0200, Simon Josefsson wrote:
> >> > Why certtool request for a int number for serial?, if I think
that
> >> > should be >= unsigned long long (64 bit):
> >> 
> >> Hello.  'Unsigned long long' is a non-standard C extension, is it
not?
> >> We want the code to work with standard compilers.
> >
> > No, it's C99. If you'd rather have POSIX, use uint64_t.
> 
> I believe the goal is for GnuTLS to work on C89 platforms.  'long
> long' isn't used by GnuTLS today.  Further, according to:
> 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
> 
> uint64_t is not required by POSIX, it is optional.  uint64_t is also
> not used by GnuTLS today.  So I don't think neither is a good solution
> here.
> 
> X.509 serials are frequently larger than 64 and even 128 bits, so the
> real solution would be to make get_serial return a hex string instead.
> Then we won't have arbitrary limits, be them 32, 64 or 128 bits.
> Fixing that look rather simple; patches welcome.
> 
> Regards,
> Simon
> 
> 
> _______________________________________________
> Help-gnutls mailing list
>