Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Nov 2006 09:53:43 +0100

May I repeat my request for further improving the interoperability in this area?
Anyway, here it is:

4.2.2.1  Authority Information Access

When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an
 accessLocation that is an HTTP [RFC 1738] or LDAP [RFC 4516] URI. there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516] accessLocation URI specified.

Rationale:
Since LDAP has rather limited applicability on public networks, I believe that [indirectly] requiring mandatory LDAP support on COTS clients may prove to be hard to motivate for AIA access.  One may argue that reading AIA extensions is just an option but that is not really the case; schemes like PIV require that you interpret AIA in order to create valid certification paths, unless you force clients to store additional CA certificates locally which is a less optimal solution.  The cost for a CA to support HTTP and LDAP AIAs is close to zero since this is built-in in the leading CA packages on the market.   That the PIV certificate requirements also specify both URI types for AIA probably was probably not accidental.

Sincerely
Anders Rundgren

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 16 Nov 2006 18:32:39 +0800

I oppose this change of AIA extension. There already exists some
CAs that issued certificates with AIA extensions containing only
one id-ad-caIssuers accessLocation (either HTTP or LDAP). This
change will immediately make these CAs becoming non-compliant
to RFC3280bis. For a CA to guide its relying parties (client applications)
where to find the CA certificates, one  id-ad-caIssuers accessLocation
is sufficient. Even though the leading CA packages one the market
support both HTTP and LDAP, certification service providers might
still choose not to deploy both kinds of repositories at the same time because
of concerning the operating cost. There is no enough reason to require all
compliant CAs to both kinds of repositories at the same time. I prefer to
leave the current text as it is. With current text,  certification service
providers are free to choose HTTP or LDAP or both.

Wen-Cheng Wang
  ----- Original Message ----- 
  From: Anders Rundgren 
  To: [email-masked] 
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 

  Rationale:

  Sincerely
  Anders Rundgren

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 16 Nov 2006 18:32:39 +0800

Wen-Cheng Wang
  ----- Original Message ----- 
  From: Anders Rundgren 
  To: [email-masked] 
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 

  Rationale:

  Sincerely
  Anders Rundgren

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Nov 2006 19:19:14 +0100

Wen-Cheng Wang wrote:

>one id-ad-caIssuers accessLocation (either HTTP or LDAP). 

Sure.  Since RFC 3280 says nothing about this we can expect some variations out there.

>This change will immediately make these CAs becoming non-compliant
>to RFC3280bis.

Does it?  I thought SHOULD is a recommendation.

>For a CA to guide its relying parties (client applications)
>is sufficient.

You misunderstood my point.  Certificate path building on the relying parties' end is (with S/MIME as the only major exception), done by servers.  For servers there is no problem to fix.  I'm rather talking about client software that is not relying party software, but rather subscriber software.  Although some CAs indeed not only specify and distribute such software, it is not these guys who have a problem, it is rather the other 99% who can't afford writing their own subscriber software.

>Even though the leading CA packages one the market

Yes, but makers of client software MUST (otherwise they cannot create a proper cert-path), support both in order to work with compliant CAs.

It is really the concern of CAs or of a gazillion clients that is the core issue.

It is interesting to note that NIST came to a different conclusion regarding PIV than for 3280bis, in spite of having pretty much the same people behind both efforts.

Anders
  ----- Original Message ----- 
  From: Anders Rundgren 
  To: [email-masked] 
  Sent: Thursday, November 16, 2006 4:53 PM
  Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-06.txt 

  Rationale:

  Sincerely
  Anders Rundgren

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 Nov 2006 10:26:23 -0500

>Does it?  I thought SHOULD is a recommendation.

SHOULD means that an implementation is expected to provide the 
indicated functionality unless there is a REALLY GOOD reason not to. 
This makes it much more than a recommendation.

>You misunderstood my point.  Certificate path building on the 
>relying parties' end is (with S/MIME as the only major exception), 
>done by servers.  For servers there is no problem to fix.  I'm 
>rather talking about client software that is not relying party 
>software, but rather subscriber software.  Although some CAs indeed 
>not only specify and distribute such software, it is not these guys 
>who have a problem, it is rather the other 99% who can't afford 
>writing their own subscriber software.

Cert path building and validation is currently assumed (by our 
standards) to be performed by an RP, The rationale for creating SCVP 
is precisely to allow off-loading of cert path building and/or 
validation. Thus your comment above is not consistent with RFC 3280. 
Also, the term "subscriber" appears nowhere in  3280, so your 
reference to that term above is context-free.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Mon, 20 Nov 2006 13:36:59 +0100

Anders Rundgren wrote:
> When the id-ad-caIssuers accessMethod is used, 
> [..]
> there SHOULD be at least one HTTP [RFC 1738] and one LDAP [RFC 4516]
> accessLocation URI specified. *

I fail to see the benefit of using "and" instead of "or" here.

Note that most times LDAP servers are hidden behind firewalls.

Ciao, Michael.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Nov 2006 13:03:25 +0000

> Note that most times LDAP servers are hidden behind firewalls.

So, it looks like only Anders wants this change and its opposed
by some people which'd argue that David ought to leave things
just as they are.

S.

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Nov 2006 19:19:06 +0100

>by some people which'd argue that David ought to leave things

Sure, David have already defined this the way I propose in "his"
(NIST's) interpretation/profile of RFC3280bis, FIPS201.
Probably with the same prime motive as I; to foster interoperability
among a wide range of standard and custom client software and devices.

In the presumably rare case you are in full control over the entire spectrum
of apps, you may IMHO do whatever you want.

Hopefully the FIPS201 document will serve as the "gold standard" in this
respect rather than RFC3280bis.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 23 Nov 2006 11:31:47 +0000

Anders, I disagree with you proposal. It makes no sense to me to do such recommendation in the generic profile.

It is a totally different thing to make such SHOULD requirement in an interoperability profile than making it an a base standard like RFC 3280bis.

What ever goes into RFC 3280bis must be reasonable for all implementations, not only those with a certain scope of interoperability.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Anders Rundgren
> Sent: den 20 november 2006 19:19
> To: Stephen Farrell; Michael Ströder
> Cc: [email-masked]