Subject: amsl.com certificate?

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 20 Feb 2008 18:04:05 +0100

I just registered for IETF-71 and tried to pay. I wasn't bothered too  
much when I got an SSL warning for the former, but I hesitate to  
proceed with the latter, which is also under the amsl.com domain.

My browser (the latest version of Safari on the Mac) complains that  
the issuer of the certificate is untrusted. That would be Starfield  
Secure Certification Authority.

Is this a CA in good standing that we should trust?

Iljitsch
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 20 Feb 2008 19:00:13 +0100

> Secure Certification Authority.

On <http://www.starfieldtech.com/products/faq.htm> they apparently 
say that it should work with Safari on Mac OS X 10.3.4 or higher.

> Is this a CA in good standing that we should trust?

It is up to you to decide this.  Some years ago I wanted to install
their root CA with a Netscape 3.x, they offered a SHA-1 fingerprint,
my browser showed an MD5 fingerprint.  After an unsuccessful attempt
to ask their support what the MD5 fingerprint is I decided that I 
don't need their root certificates.

If you trust that amsl.com really is amsl.com from your POV that is
beside the point, isn't it ?  
    
 Frank

---

From: "Daniel Brown" <[email-masked]>
Date: Wed, 20 Feb 2008 13:03:54 -0500

On Feb 20, 2008 12:04 PM, Iljitsch van Beijnum <[email-masked]> wrote:
[snip!]
> Is this a CA in good standing that we should trust?

    Starfield Tech is the company from whom the certificate is issued
if you purchase an SSL certificate through GoDaddy.

-- 
</Dan>

Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: David Morris <[email-masked]>
Date: Wed, 20 Feb 2008 10:12:45 -0800 (PST)

Don't know if this is the case, but using a GoDaddy certificate requires
that you enable chaining ... may be that installtion of the chained certs
wasn't done correctly.

Knowing that amsl.com is amsl.com is only part of the SSL issue. If the
cert is wrong, do you trust that the encryption derrived from the
questionable cert is complete?

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Feb 2008 13:16:43 -0500

--On Wednesday, 20 February, 2008 13:03 -0500 Daniel Brown
<[email-masked]> wrote:

> On Feb 20, 2008 12:04 PM, Iljitsch van Beijnum
> <[email-masked]> wrote: [snip!]
>> My browser (the latest version of Safari on the Mac)
>> complains that the issuer of the certificate is untrusted.
>> That would be Starfield Secure Certification Authority.
>> 
>     Starfield Tech is the company from whom the certificate is
> issued if you purchase an SSL certificate through GoDaddy.

And that is supposed to inspire confidence?

    john

---

From: "Daniel Brown" <[email-masked]>
Date: Wed, 20 Feb 2008 13:20:01 -0500

> And that is supposed to inspire confidence?

    Confidence is subjective.  I was merely stating fact.

-- 
</Dan>

Daniel P. Brown
Senior Unix Geek

---

From: James Galvin <[email-masked]>
Date: Wed, 20 Feb 2008 13:45:51 -0500

AMS obtains certificates for their clients from Starfield 
Technologies:

    <http://www.starfieldtech.com/>

Do you have a concern about this choice or is your concern about 
the fact that your browser didn't accept the certificate by default?

If you have a concern about this choice it would help if you could 
be specific about what that is.  Their web site seems pretty 
complete to me so any one of us could "check them out."  I think we 
need to trust AMS to make a good choice unless we can identify an 
issue.

As far your browser not accepting the certificate, I'm sure you 
realize there a lot of reasons that could happen including the 
latest version of Safari "missing" a particular root certificate.

Jim

-- On Wednesday, February 20, 2008 6:04 PM +0100 Iljitsch van 
Beijnum <[email-masked]> wrote regarding amsl.com certificate? 
--

> I just registered for IETF-71 and tried to pay. I wasn't bothered
> too   much when I got an SSL warning for the former, but I
> hesitate to   proceed with the latter, which is also under the
> amsl.com domain.
>
> My browser (the latest version of Safari on the Mac) complains
> that   the issuer of the certificate is untrusted. That would be
> Starfield   Secure Certification Authority.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Feb 2008 11:28:09 -0800

>latest version of Safari "missing" a particular root certificate.

...or there is a configuration issue with your particular copy of 
Safari. I can go to the registration page just fine on "the latest 
version of Safari" without hitting any dialog boxes. Safari tells me 
that the cert is valid.

--Paul Hoffman, Director
--VPN Consortium
IETF mailing list
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2008 10:15:56 +1100

> version of Safari" without hitting any dialog boxes. Safari tells me 

	It's not just Safari, it's also Firefox.

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20080126 Firefox/2.0.0.11

	Note: Firefox has a root cert from them.  Just not the one
	that signed this cert.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Feb 2008 00:46:44 +0100

> the fact that your browser didn't accept the certificate by default?

The latter.

> latest version of Safari "missing" a particular root certificate.

Right. Not sure what it was in this case, because when I tried it just  
now from home, first with Firefox and then again with Safari, there  
were no problems.

I would have been surprised if AMSL had used a CA that isn't widely  
accepted by default, because that requires people to install a new  
root certificate, which is a somewhat big deal: you wouldn't want to  
install a "bad" root certificate so this involves a fair amount of  
checking.

> 	Note: Firefox has a root cert from them.  Just not the one

What I'm seeing right now is a certificate from AMSL with SHA-1  
fingerprint

9F B6 01 FE 68 40 BB F6 6F 55 06 28 7C 42 15 01 38 0A CA 66

signed by a Starfield certificate with SHA-1 fp

7E 18 74 A9 8F AA 5D 6D 2F 50 6A 89 20 FF 22 FB D1 66 52 D9

and then one with SHA-1 fp

36 3E 47 34 F7 57 BD EB 89 86 8E FE 94 90 77 74 A3 27 69 5E

which is signed by Valicert with SHA-1 fp

31 7A 2A D0 7F 2B 33 5E F5 A1 C3 4E 4B 57 E8 B7 D8 F1 FC A6

Iljitsch

---

From: Alexa Morris <[email-masked]>
Date: Wed, 20 Feb 2008 17:06:59 -0800

As soon as the SSL problem was reported, AMS performed additional testing on
many different computers. However, we were unable to duplicate this problem.
If someone else experiences this issue and is concerned, please send an
email [email-masked]. Alternatively, please feel free to contact me
directly at any time.

Regards,
Alexa

-----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [email-masked]

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Feb 2008 13:24:00 +1100

The default setting in Firefox (and possibly safari) is to use OCSP for 
validation of certificates where OCSP is referenced. The *.ietf.org 
certificate has as part of the Authority Information Field the value; 
OCSP: URI: http://ocsp.starfieldtech.com

This url is unreachable from many non-US sites, for reasons known only 
to Godaddy I presume.

The pragmatic workaround in firefox is to set the option to not using 
OCSP for certificate validation.

Geoff

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Feb 2008 11:15:41 +0100

> This url is unreachable from many non-US sites, for reasons known only

Or Akamai. It turns out that I get different addresses for this FQDN  
depending whether I'm at home or at work, see traceroutes. (#include  
<stdanycastisevil.h>) At home, everything works in both Safari and  
Firefox on the Mac, at work it doesn't, even though I can open this  
URL. Also tried with the ancient Internet Explorer for Mac and with  
IE and Firefox on Windows XP, those don't seem to be bothered in the  
same way as Safari and Firefox under MacOS.

Currently, Safari tells me that certificate with SHA-1 fingerprint 9F  
B6 01 FE 68 40 BB F6 6F 55 06 28 7C 42 15 01 38 0A CA 66 is signed by  
an unknown authority. I can't copy/paste the details and they don't  
show any areas that seem problematic to my untrained eye.

$ traceroute ocsp.starfieldtech.com
traceroute: Warning: ocsp.starfieldtech.com has multiple addresses;  
using 68.178.232.168
traceroute to balance.godaddy.com.akadns.net (68.178.232.168), 64 hops  
max, 40 byte packets
  1  192.168.0.1 (192.168.0.1)  2.953 ms  1.308 ms  1.660 ms
  2  static-1-138-7-89.ipcom.comunitel.net (89.7.138.1)  7.799 ms   
7.567 ms  10.979 ms
  3  10.4.0.169 (10.4.0.169)  9.968 ms  9.400 ms  8.730 ms
  4  212.145.3.222 (212.145.3.222)  9.527 ms  10.969 ms  8.733 ms
  5  MAD06RI01-Vlan2.ipcom.comunitel.net (212.145.4.76)  8.834 ms   
9.536 ms  9.386 ms
  6  mad3-core-1.gigabiteth4-0-0s152.swip.net (130.244.218.125)   
10.211 ms  9.008 ms  9.280 ms
  7  cbv-core-1.pos4-0-0.swip.net (130.244.207.149)  44.177 ms  44.711  
ms  46.704 ms
  8  cbv1-core-1.gigabiteth1-0-0.swip.net (130.244.206.254)  35.776  
ms  35.769 ms  35.839 ms
  9  cbv1-core-2.tengigabiteth2-1.swip.net (130.244.49.70)  35.823 ms   
35.002 ms  35.085 ms
10  pnias1257-gi-1-8.mpr2.cdg2.fr.above.net (84.207.23.161)  47.905  
ms  47.796 ms  51.746 ms
11  so-5-0-0.cr1.lhr3.uk.above.net (64.125.23.13)  57.632 ms  
so-4-0-0.cr1.lhr3.uk.above.net (64.125.23.9)  48.694 ms  
so-5-0-0.cr1.lhr3.uk.above.net (64.125.23.13)  48.102 ms
12  so-1-0-0.mpr1.lhr2.uk.above.net (64.125.28.38)  50.884 ms  53.369  
ms  56.308 ms
13  so-0-1-0.mpr1.dca2.us.above.net (64.125.27.57)  125.341 ms   
122.779 ms  126.148 ms
14  so-1-0-0.mpr3.iah1.us.above.net (64.125.29.37)  151.115 ms   
150.661 ms  149.343 ms
15  so-1-2-0.mpr2.phx2.us.above.net (64.125.25.10)  173.681 ms   
172.848 ms  174.637 ms
16  64.124.113.62.godaddy.com (64.124.113.62)  193.435 ms  196.808 ms   
192.744 ms
17  ip-208-109-112-137.ip.secureserver.net (208.109.112.137)  191.233  
ms  191.285 ms  191.658 ms
18  ip-208-109-112-161.ip.secureserver.net (208.109.112.161)  193.251  
ms  193.847 ms  198.613 ms
19  ip-208-109-112-145.ip.secureserver.net (208.109.112.145)  191.353  
ms  191.677 ms  191.336 ms
20  ip-208-109-112-181.ip.secureserver.net (208.109.112.181)  193.680  
ms  193.357 ms  191.327 ms
21  *^C

$ traceroute ocsp.starfieldtech.com
traceroute: Warning: ocsp.starfieldtech.com has multiple addresses;  
using 66.29.45.240
traceroute to balance.godaddy.com.akadns.net (66.29.45.240), 64 hops  
max, 40 byte packets
  1  faro.it.uc3m.es (163.117.140.2)  1.643 ms  0.249 ms  0.251 ms
  2  rtr-dep-it.uc3m.es (163.117.31.2)  0.524 ms  0.952 ms  0.653 ms
  3  163.117.32.25 (163.117.32.25)  0.801 ms  0.765 ms  0.693 ms
  4  rtcm-cr1-uc3m.redimadrid.madrimasd.org (193.145.14.22)  1.244 ms   
1.182 ms  1.114 ms
  5  * XE1-0-0-101.Madrid0.red.rediris.es (130.206.215.65)  1.949 ms   
1.550 ms
  6  MAD.XE7-0-0.EB-IRIS4.red.rediris.es (130.206.250.21)  1.759 ms   
1.658 ms  1.767 ms
  7  mad-b1-link.telia.net (213.248.70.249)  1.779 ms  1.951 ms  1.830  
ms
  8  prs-bb1-link.telia.net (80.91.248.128)  17.996 ms  18.028 ms   
18.564 ms
  9  nyk-bb1-link.telia.net (80.91.251.96)  92.529 ms  92.341 ms   
92.403 ms
10  nyk-b3-link.telia.net (80.91.250.9)  95.496 ms  95.396 ms  95.565 ms
11  netaccess-114875-nyk-b3.c.telia.net (213.248.83.186)  99.456 ms   
99.567 ms  99.484 ms
12  0.e1-3.tbr2.tl9.nac.net (209.123.10.74)  99.636 ms  99.424 ms   
99.405 ms
13  0.e1-4.tbr2.mmu.nac.net (209.123.10.77)  101.567 ms  101.363 ms   
101.724 ms
14  vlan804.esd2.mmu.nac.net (209.123.10.14)  102.063 ms  101.751 ms   
107.595 ms
15  0.ge-0-1-0.dar1.mmu.nac.net (209.123.11.110)  101.843 ms  101.508  
ms  101.354 ms
16  mail.thecountryclubrich.com (66.29.45.240)  100.244 ms  100.416  
ms  100.928 ms

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2008 07:22:31 -0800

At Wed, 20 Feb 2008 18:04:05 +0100,
> Is this a CA in good standing that we should trust?

So, what puzzles me here is:
Why is this going to amsl.com at all? It seems extremely
desirable to have a set of names and credentials that point
only to *ietf.org, both to keep interfaces consistent and
to avoid issues with referential integrity in future
transitions.

-Ekr

---

From: SM <[email-masked]>
Date: Thu, 21 Feb 2008 09:05:40 -0800

>to avoid issues with referential integrity in future

Good question.  It would have been better to have the registration 
site under *.ietf.org instead of being directed to a third-party 
site.  It may inspire more confidence.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Feb 2008 12:57:11 -0500

Timing did not allow this approach.  Registration for this meeting is 
being handled by AMS, our new Secretariat vendor.  However, we needed 
to open registration for this meeting before ietf.org was moved from 
the old Secretariat vendor to the new one.  This approach seemed like 
the best way to deal with the transition.

Russ

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Feb 2008 15:02:26 -0500

--On Thursday, 21 February, 2008 12:57 -0500 Russ Housley
<[email-masked]> wrote:

> Timing did not allow this approach.  Registration for this
> meeting is  being handled by AMS, our new Secretariat vendor.
> However, we needed  to open registration for this meeting
> before ietf.org was moved from  the old Secretariat vendor to
> the new one.  This approach seemed like  the best way to deal
> with the transition.

Russ,

Taking this as a given, can we be assured that future meetings
will be handled exclusively from ietf.org?  If so, then I think
we should, to the extent possible, write the issues with the
amsl.com certification off as a transition issue and move on.
If not, I would think that this discussion ought to expand into
examining the question of whether the example IETF sets ought to
involve certificate authorities and types that actually verify
an organization's identity and status, not just the ability to
obtain a domain name and set up a web site.

     john

>> Good question.  It would have been better to have the
>> registration site under *.ietf.org instead of being directed
>> to a third-party site.  It may inspire more confidence.
>> 
>> Regards,
>> -sm
>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Feb 2008 15:57:01 -0500

>obtain a domain name and set up a web site.

I'm investigating.  If I have not reported an answer by the IESG/IAOC 
plenary at IETF 71, then please ask.

Russ