Subject: RE: On cross-certificates and pathLenConstraint

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Sep 2004 12:44:56 -0400

At 4:38 PM +0100 9/9/04, Stefan Santesson wrote:
>No I'm not saying that.
>MS CAPI will process the root extensions and you can't turn that off.
>

Stefan,

So, are you saying that MSCAPI pays attention to all extensions in a 
TA cert is when performing path validation?  if so, then it is 
non-compliant with the current X.509 and RFC 3280 (and RFC 2459) 
specs, because those specs say to NOT pay attention to name 
constraints in a TA.  Personally I would rather have cert processing 
pay attention to these extensions, but all of these specs say the 
opposite (in terms of this extension) and that has been true for some 
time.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 11 Sep 2004 15:30:51 +1200

Stephen Kent <[email-masked]> writes:

>So, are you saying that MSCAPI pays attention to all extensions in a TA cert
>is when performing path validation?  if so, then it is non-compliant with the
>current X.509 and RFC 3280 (and RFC 2459) specs, because those specs say to
>NOT pay attention to name constraints in a TA.  Personally I would rather
>have cert processing pay attention to these extensions,

cryplib does this as well, and a number of other implementations (whom I
probably can't speak for, but in case anyone involved with them is still
reading this list they may want to speak out) do as well.

A while back I performed an informal survey of users to see what they'd do if
my code ignored extensions in root certs/trust anchors/whatever.  100% of
respondents said they'd file bug reports against cryptlib if the code did
that.  Now admittedly it wasn't a very large survey, everyone I asked regarded
software that did this as faulty so I stopped asking after awhile since it
didn't look like the answer would change.

>all of these specs say the opposite (in terms of this extension) and that has
>been true for some time.

This seems to be another instance of the PKIX disconnect-from-reality effect
at work.

Peter (who is now in the novel position of defending MS's non-compliance with
       standards... OTOH we seem to be in good company with this).

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 11:24:33 -0400

Peter,

As I noted earlier in my messages, I think it would be appropriate to 
include these extensions in path validation. In fact, I raised this 
issue over a year ago in discussions with Sharon and Sanrtosh. But, 
X.509 does not allow this at this time. So, PKIX was trying to 
maintain compatibility with X.509 in this regard. So your ire is more 
appropriately directed toward X.509, not PKIX.  When X.509 is 
changed, I expect we can update 3280 as well.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Sep 2004 22:23:02 +1200

Stephen Kent <[email-masked]> writes:

>As I noted earlier in my messages, I think it would be appropriate to include
>these extensions in path validation. In fact, I raised this issue over a year
>ago in discussions with Sharon and Sanrtosh. But, X.509 does not allow this at
>this time.

If there's consensus that this is a good idea, why not just change it?  PKIX
is bigger than X.509 (does anyone still work from X.509 rather than going
straight to the PKIX sources)?  I know that PKIX was originally started to
profile X.509 for Internet use, but it's been running (or at least shuffling)
as a full parallel standards group for years since then.  PKIX is the dog,
X.509 is its vestigial tail, why not wag it?

(I'm not trying to pick a fight with the X.509 folks, it's just a pain having
 two (more if you include ETSI and other groups) parallel standards bodies all
 busy cutting&pasting each other's work as they play Chinese Whispers with the
 spec, with sundry propagation delays, inconsistencies, and errors introduced
 along the way).

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Sun, 19 Sep 2004 18:39:38 -0400

Peter,

We have discussed the issue with Sharon, a while ago, and she is 
working to get the change into X.509.  We can then update 3280 and 
maintain sync.  PKIX has rarely diverged from X.509 in a way that 
caused compatibility problems, although it has happened on a coupe of 
occasions.  It was always painful and confusing to the larger 
community, so we try to avoid this problem.

Steve