multiple Common Name fields

Miles Nordin wrote:

>      d> There are very few browsers that don't
support subjectAltNames
>      d> (mostly ones that aren't maintained like
lynx)...
> 
> so we agree on point #1, we mostly want to follow the
browsers, not
> necessarily the RFC.

In this case the browsers are clients and may dictate the
direction with
the RFCs, but we are following RFCs, if you don't like it
get on the
IETF working groups doing all this up and have your say
there. At this
point in time most people seem to care most about browser
inclusion, so
when you get one group over whelmingly wanting one action,
and at the
same browsers expecting CAs to follow certain RFCs what
would you be doing?

> Are you saying you need to hear it from more than one
person before
> looking into it more carefully?  It seems like you can
just have a

This has nothing to do with looking into anything, but at
the same time
it's pretty clear what direction people expect CAcert to go
in, and to
get from point a to point b there is a whole bunch of steps.

> look at the cert I was issued and see for yourself. 
Either you can
> explain it or you can't.  No need to suggest I'm crazy
because I'm one
> person. 

There is no problem with Thunderbird and other browsers that
follow RFCs
correctly... As I stated before perhaps the software not
"working" needs
to have a bug filed against it for not following the
standards everyone
else is, what if the same software didn't work properly with
smtp or
pop3 or imap, would people be screaming about changing these
other
protocols or would they be screaming to have the software
developers fix
the software? Standards exist so software can interop...

> so.. assuming for the sake of argument that XMPP
somehow goes into
> subjectAltName as an unparseable, duplicated component
(seems odd), I
> still wonder, why is the DNS:castrovalva.Ivy.NET
subjectAltName
> repeated twice?  That seems wrong to me, but maybe I'm
missing
> something?

It's not unparsable, just doesn't get displayed in human
readable
format, there is a big difference...

> I should clarify though---I'm talking about my
particular certificate
> request, which included a subjectAltName in the request
and was, as
> far as I can tell from your documentation, correct,
because I read the
> conflicting information on the Wiki carefully.  I'm
saying, if you are

Wiki shouldn't ever be considered authoritative because one
it can be
edited by anyone, and due to lack of people helping to keep
things up to
date, do you feel like helping out and making things correct
at all? 

> going to mangle certificates for requests you feel are
incorrect, we
> can't all agree on that.  But I think we can all agree
that the
> mangling shouldn't _require_ your request to be in some
common
> incorrect format, and mess up when you submit an actual
correct
> request like I did.

The Server spits out "correct" formatting, any
mangling done is for the
benefit of users that don't have the time to search our
relevent
documentation and do what they think is correct, which
isn't, see the
point I made about pop3 not being followed, or smtp not
being followed,
these are all RFCs put out by the IETF, and while there is a
lot of
discussion on how wishy washy some of the RFCs can be, the
subjectAltName thing is pretty strict. You can't have it
both ways, do
you want some standards followed but not others?

> In my admittedly inexperienced opinion, you should
document how to
> make correct requests rather than mangling certs, but
we disagree

We have, 2 people even published a perl and shell script to
generate
correct requests, what more can we be expected to do?

> there.  We would probably both agree that we should fix
the Wiki if
> there is not enough documentation for a careful person
to submit a
> request that you call ``correct.''  I'm willing to try
to translate

Is that an offer to help ? 

> mailinglist+RFC into documentation for the wiki, but I
can't do it yet
> because I can't infer what the mangling rules are based
on what I've
> learned so far.  I don't understand the subjectAltName
that OpenSSL
> can't parse, nor why the DNS:castrovalva.Ivy.NET
subjectAltName is
> repeated twice.

Every change generates an email to core supporters (anyone
can get the
same emails but most don't care or want them), if there is
information
that is overly incorrect it will be reverted or fixed
further.

-- 

Best regards,
 Duane

http://www.cacert.org -
Free Security Certificates
http://www.nodedb.com -
Think globally, network locally
http://www.sydneywirele
ss.com - Telecommunications Freedom
http://e164.org - Because
e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

>>>>> "d" == Duane  <duanecacert.org> writes:

     d> There is no problem with Thunderbird and other
browsers that
     d> follow RFCs correctly... As I stated before
perhaps the
     d> software not "working" needs to have a
bug filed against

I think you are confusing my problem with the guy who wanted
multiple
CN's in the cert's DN.  They are two separate problems,
although they 
both involve mangling.

I agree you should not issue certs with multiple CN's.  I'd
be happier
if you would simply reject the request rather than mangling
it, but
that's not my main problem either.

The main problem is the duplicated entries in the
subjectAltName.  Any
idea what's going on there?

     d> do you feel like helping out and making things
correct at all?
     d> 

I do. 
However I cannot fabricate information---I have to ask for
it. 
 I can
do some testing and then ask when I get confused.
Which is what I did here---I posted a cert and then asked
why does it
have duplicated entries in subjectAltName?  Any ideas?  We
got the
openssl-unparsed thing somewhat clearer, but on the other
point we
seem to just be going back and forth with no answer. 

     d> for the benefit of users that don't have the time
to search
     d> our relevent documentation and do what they think
is correct,

You don't have relevant documentation for the way the
mangling works
right now, and I think that needs to be added, or else the
mangling
turned off.

the vhost documentation should be cleaned up---it is more
like a
scratchpad than documentation.

There is also incorrect/outdated documentation about
wildcard certs,
implying that they don't work, while cacert is using one
themselves.

so I think we all agree there is need for documentation
improvement,
but that will require some digging for the facts of how
CACert works
right now.

     d> You can't have it both ways, do you want some
standards
     d> followed but not others?

I want either (1) certificates you feel are incorrect to be
rejected
rather than mangled, -*OR*- someone to understand and
explain the
mangling so we can verify it is correct (it looks wrong in
my cert, to
me), and then get it documented.

The XMPP openssl-unparseable field is somewhat explained, so
maybe I
can find the RFC and read it for the rest of the story.  An
RFC number
would help me get started faster.  We are still left with
the problem
of the duplicated subjectAltName though.  That's not
explained, and
this is like the fourth time I've asked about it! 

     d> We have, 2 people even published a perl and shell
script to
     d> generate correct requests, what more can we be
expected to do?

document it in English.  I don't find shell scripts a
substitute.

     d> Is that an offer to help ? 

Yes.  but see questions above.
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support

Currently there is confusion over how CAcert issues
certificates, namely
people expecting certificates with multiple commonNames
(CNs) to be
signed by CAcert, however testing in the past has shown that
certificates issued with multiple CNs only works in MS IE,
other
browsers that follow RFCs more strictly ignore all CNs after
the first
one. More recently it's been claimed that The Bat! works
correctly with
multiple CNs, but does not recognise subjectAltNames (SANs)
at all.

The reason for this is because CNs were never part of any
formal
document released by any recognised standards body and RFCs
that have
been released (RFC 2459, 2818, 3280, 4513) that touch the
topic of
hostnames in certificates only mention that CNs have been
depreciated in
favour of SANs.

CNs came about but never standardised when Netscape was
developing SSL2
and became a widely used de-facto standard, however with the
release of
RFC 2459 SANs became recognised as a standard and their use
has been
encouraged ever since.

While RFC 2818 deals with HTTP over TLS, this is one of many
RFCs that
reinforces the sentiments of RFC 2459. Opinions have been
expressed that
part of the intent of authors in writing RFCs 2459 and 2818
were to
hasten the demise of CNs in certificates.

-- 

Best regards,
 Duane

http://www.cacert.org -
Free Security Certificates
http://www.nodedb.com -
Think globally, network locally
http://www.sydneywirele
ss.com - Telecommunications Freedom
http://e164.org - Because
e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Support mailing list
CAcert-Supportlists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/
cacert-support