Subject: R: On cross-certificates and pathLenConstraint

From: "Santoni Adriano" <[email-masked]>
Date: Tue, 31 Aug 2004 12:48:29 +0200

Thank you for clarifying your thought.

It seems to me, however, that some aspects to this topic are still a little blurry.

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: martedì 31 agosto 2004 12.26
A: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in roots but any present path length constraints, policy constraints, explicit policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour any constraints set in the root certificate so MS CAPIs decision to enforce ROOT extensions in this manner is not in conflict with RFC 3280, but you can't rely on that other RFC 3280 compliant implementations will do this. They may legitimately ignore this data.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Santoni Adriano
> Sent: den 31 augusti 2004 09:26
> To: Peter Hesse; David P. Kemp
> Cc: [email-masked]
> Subject: R: On cross-certificates and pathLenConstraint
> 
> 
> If I am getting you right, you are saying that the exensions in the 
> self- signed certificate of a trust anchor (root CA) should be 
> ignored. This is quite suprising to me!
> 
> I thought it perfectly made sense to insert in a root CA certificate a 
> basicConstraints with cA=TRUE and pathLenConstraint=0 (for example) to 
> signify that that CA only issues certificates to end-users and not to 
> subordinates. I am talking about the self-signed certificate used by 
> an autonomous CA to distribute its own public key in a way that allows 
> easy import into virtually all applications. [On the other hand, what 
> CAs distribute their own public keys as a bare public keys? Virtually 
> none.]
> 
> It suddenly comes to my mind that perhaps the extensions in the root 
> CA certificates contained in the Windows store were inserted for the 
> sole purposes of accommodating MS CAPI idiosyncrasies (like mentioned 
> by
> Santesson) ...
> 
> However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> 	"...This extension MUST appear as a critical extension in all CA 
> certificates
> 	that contain public keys used to validate digital signatures on 
> certificates" ?
> 
> (and the same hold for other extensions as well)
> 
> It does not say "all CA certificates that are not trust anchors"; it 
> says "all CA certificates".
> 
> Is this statement not conflicting with your one?
> 
> Adriano
> 
> 
> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] 
> Per conto di Peter Hesse
> Inviato: lunedì 30 agosto 2004 18.43
> A: 'David P. Kemp'; [email-masked]
> Oggetto: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Section 6.1 of RFC 3280 states:
> 
>    When the trust anchor is provided in the form of a self-signed
>    certificate, this self-signed certificate is not included as part of
>    the prospective certification path.  Information about trust anchors
>    are provided as inputs to the certification path validation algorithm
>    (section 6.1.1).
> 
> Thus I agree with Santosh that in no case should the extensions in a 
> trust anchor's self-signed certificate affect the certification path 
> validation.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been a 
> statue set up in honor of a critic." --Jean Sibelius
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of David P. Kemp
> > Sent: Monday, August 30, 2004 11:51 AM
> > To: [email-masked]
> > Subject: Re: On cross-certificates and pathLenConstraint
> >
> >
> > Santosh,
> >
> > Is there ambiguity in the term trust anchor?  It seems possible to 
> > regard the trust anchor as a bare public key or as a certificate.
> >
> > Because a self-signed certificate should appear only once at the 
> > head of a path (and never elsewhere) the rule of "no extensions in 
> > trust anchors" should apply only if "trust anchor" is defined to be 
> > a public key that can be used to verify a certificate (self-signed 
> > or otherwise).  It should not apply if the self-signed certificate 
> > itself is defined to be the trust anchor.
> >
> > Perhaps X.509 and RFC 3280 should be clarified to state that there 
> > is no such thing as a "self signed root".  There are roots (trust 
> > anchors) that are public keys only, and there are self signed 
> > certificates that may be validated by a root and whose extensions 
> > are to be honored.
> >
> > Dave
> >
> >
> > Santosh Chokhani wrote:
> >
> > >Stefan:
> > >
> > >I think extensions should be ignored in the trust anchor
> > regardless of
> > >their criticality
> > >
> > >For reasons such as MS CAPI, it is best to keep the trust anchors 
> > >to bear minimum required.
> > >
> > >-----Original Message-----
> > >From: Stefan Santesson [mailto:[email-masked]]
> > >Sent: Saturday, August 28, 2004 5:10 AM
> > >To: Santosh Chokhani; [email-masked]
> > >Subject: RE: On cross-certificates and pathLenConstraint
> > >
> > >
> > >The case when CA A is a self-signed root is different.
> > >
> > >If the Path Length constraint is present in the self signed root, 
> > >it will be ignored by a X.509 and RFC 3280 compliant path
> > validation implementation.
> > >
> > >However, there are implementations that honour Root
> > extensions despite
> > >this and would thus honour Path length constraints present in 
> > >roots. E.g. I know that MS CAPI will.
> > >
> > >Despite that, I would say that it is wrong to rely on critical 
> > >extensions in root certificates since they are ignored in
> > RFC 3280 path validation.
> > >
> > >Stefan Santesson
> > >Microsoft Security Center of Excellence (SCOE)
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked] 
> > >>[mailto:[email-masked]]
> > >>On Behalf Of Santosh Chokhani
> > >>Sent: den 28 augusti 2004 00:52
> > >>To: [email-masked]
> > >>Subject: RE: On cross-certificates and pathLenConstraint
> > >>
> > >>
> > >>Stefan has the right idea.
> > >>
> > >>If CA A is simply another CA, CA B certificate can be
> > validated as an
> > >>end (not intermediate certificate).
> > >>
> > >>If CA A is trust anchor, I think it can issue CA
> > certificates.  I read
> > >>both X.509 and 3280 to not enforce constraints in the trust 
> > >>anchor.
> > >>
> > >>To complicate matters further, if the trust anchor issues itself a 
> > >>self-issued certificate, I would think the pathLength in that 
> > >>certificate should be honored.
> > >>
> > >>BTW, all this discussion of hierarchies and cross
> > certificates should
> > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust model 
> > >>agnostic.
> > >>
> > >>-----Original Message-----
> > >>From: [email-masked] 
> > >>[mailto:[email-masked]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 9:28 AM
> > >>To: Sharon Boeyen
> > >>Cc: [email-masked]
> > >>Subject: R: On cross-certificates and pathLenConstraint
> > >>
> > >>
> > >>
> > >>Sharon,
> > >>
> > >>you explained what happens when a cross-certificates contains a 
> > >>pathLenConstraint=0, but I was referring to the
> > pathLenConstraint in
> > >>the trust-point certificate. Virtually all CA public keys are 
> > >>distributed to end-users in the form of a self-signed certificate 
> > >>which may (should) contain the BasicConstrains extension. Some EU 
> > >>profiles actually mandate the BasicConstrains to be present and 
> > >>critical.
> > >>
> > >>Using your example entities, my question can be re-phrased like
> > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > B (e.g. a
> > >>foreign one) if the self-issued certificate of CA A contains 
> > >>pathLenConstraint=0 ?
> > >>
> > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > >>
> > >>
> > >>>hierarchical SubCAs does also hinder cross-certificates?
> > >>>
> > >>>
> > >>Adriano
> > >>
> > >>-----Messaggio originale-----
> > >>Da: Sharon Boeyen [mailto:[email-masked]]
> > >>Inviato: venerdì 27 agosto 2004 14.34
> > >>A: Santoni Adriano; [email-masked]
> > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > >>
> > >>
> > >>If you are talking about a non-hierarchical trust model, then 
> > >>absolutely yes any CA can issue any cross-certificates they wish. 
> > >>However, those cross-certificates will only be trusted if paths 
> > >>are built to them that exclude the certificate that contains the 
> > >>path length constraint.
> > >>
> > >>For example, take CA A, CA B, CA C and CA D
> > >>
> > >>CA A issues a cross certificate to CA B with a path length
> > constraint
> > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross 
> > >>certificate to CA B (no path length constraint)
> > >>
> > >>Assume that there are no other cross certs in the environment
> > >>
> > >>Users of CA A have no way to trust certificates issued by CA C 
> > >>(because of the path length constraint)
> > >>
> > >>However, users of CA D are able to trust certificates
> > issued by CA C
> > >>because the cross-certificate from D to B contains no such
> > constraint.
> > >>
> > >>As for your second question, yes there are implementations that 
> > >>process paths including all the business controls. As for
> > testing, I'd
> > >>suggest you have a look at the PKITS test suite which tests
> > all these
> > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > >>
> > >>Cheers,
> > >>Sharon
> > >>
> > >>-----Original Message-----
> > >>From: [email-masked] 
> > >>[mailto:[email-masked]]
> > >>On
> > >>Behalf Of Santoni Adriano
> > >>Sent: Friday, August 27, 2004 5:37 AM
> > >>To: [email-masked]
> > >>Subject: On cross-certificates and pathLenConstraint
> > >>
> > >>
> > >>
> > >>Dear list,
> > >>
> > >>I have the following doubts regarding cross-certificates:
> > >>
> > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a cross- 
> > >>certificate to another CA in a different domain?
> > >>
> > >>In case of a "cross-certificate" (so to speak) issued by
> > the same CA
> > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to 
> > >>to allow the cross-certificate issuance regardless of the 
> > >>pathLenConstraint value, on the ground that in this case the 
> > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > >>of scope" as far as the pathLenConstraint is concerned.
> > >>
> > >>However, in the case of a "real" cross-certificate, to be issued 
> > >>to another CA with a different name, it is not very clear to me if 
> > >>the pathLenConstraint in CA1 affects the possibility of issuing a 
> > >>cross-certificate to CA2.
> > >>
> > >>By the way, I wonder how are the most widespread
> > applications handling
> > >>certificate chains containing cross-certs, in the various
> > cases (e.g.
> > >>different values of pethLenConstraint down the chain); has anybody 
> > >>done any testing to specifically investigate this area?
> > >>
> > >>Is anybody willing to shed some light and/or share informations?
> > >>
> > >>TIA,
> > >>  Adriano
> > >>
> > >>
> > >>*******************Internet Email Confidentiality
> > >>Footer*******************
> > >>
> > >>
> > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > nonche dei
> > >>suoi allegati e vietato e potrebbe costituire reato. Se ha 
> > >>ricevuto per errore il presente messaggio, Le saremmo grati se ci
> > inviasse, via
> > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > contempo alla
> > >>distruzione del messaggio stesso e dei suoi eventuali allegati. Le 
> > >>dichiarazioni contenute nel presente messaggio nonche' nei suoi 
> > >>eventuali allegati devono essere attribuite esclusivamente
> > al mittente
> > >>e non possono essere considerate come trasmesse o autorizzate da 
> > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > ACTALIS S.p.A.
> > >>nei confronti del destinatario o di terzi.
> > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali 
> > >>intercettazioni, modifiche o danneggiamenti del presente
> > messaggio e-mail.
> > >>
> > >>
> > >>
> > >>Any unauthorized use of this e-mail or any of its attachments is 
> > >>prohibited and could constitute an offence. If you are not the 
> > >>intended addressee please advise immediately the sender by
> > using the
> > >>reply facility in your e-mail software and destroy the
> > message and its
> > >>attachments. The statements and opinions expressed in this e-mail 
> > >>message are those of the author of the message and do not
> > necessarily
> > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > >>message shall be understood as neither given nor endorsed
> > by ACTALIS
> > >>S.p.A..
> > >>ACTALIS S.p.A. does not accept liability for corruption,
> > interception
> > >>or amendment, if any, or the consequences thereof.
> > >>
> > >>
> > >>*******************Internet Email Confidentiality
> > >>Footer*******************
> > >>
> > >>
> > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > nonché dei
> > >>suoi allegati è vietato e potrebbe costituire reato. Se ha 
> > >>ricevuto per errore il presente messaggio, Le saremmo grati se ci
> > inviasse, via
> > >>e-mail, una comunicazione al riguardo e provvedesse nel
> > contempo alla
> > >>distruzione del messaggio stesso e dei suoi eventuali allegati. Le 
> > >>dichiarazioni contenute nel presente messaggio nonche' nei suoi 
> > >>eventuali allegati devono essere attribuite esclusivamente
> > al mittente
> > >>e non possono essere considerate come trasmesse o autorizzate da 
> > >>ACTALIS S.p.A.; le medesime dichiarazioni non impegnano
> > ACTALIS S.p.A.
> > >>nei confronti del destinatario o di terzi.
> > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali 
> > >>intercettazioni, modifiche o danneggiamenti del presente
> > messaggio e-mail.
> > >>
> > >>
> > >>
> > >>Any unauthorized use of this e-mail or any of its attachments is 
> > >>prohibited and could constitute an offence. If you are not the 
> > >>intended addressee please advise immediately the sender by
> > using the
> > >>reply facility in your e-mail software and destroy the
> > message and its
> > >>attachments. The statements and opinions expressed in this e-mail 
> > >>message are those of the author of the message and do not
> > necessarily
> > >>represent those of ACTALIS S.p.A. Besides, The contents of this 
> > >>message shall be understood as neither given nor endorsed
> > by ACTALIS
> > >>S.p.A..
> > >>ACTALIS S.p.A. does not accept liability for corruption,
> > interception
> > >>or amendment, if any, or the consequences thereof.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> >
> 
> 
> *******************Internet Email Confidentiality
> Footer*******************
> 
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei 
> suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto 
> per errore il presente messaggio, Le saremmo grati se ci inviasse, via 
> e-mail, una comunicazione al riguardo e provvedesse nel contempo alla 
> distruzione del messaggio stesso e dei suoi eventuali allegati. Le 
> dichiarazioni contenute nel presente messaggio nonche' nei suoi 
> eventuali allegati devono essere attribuite esclusivamente al mittente 
> e non possono essere considerate come trasmesse o autorizzate da 
> ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. 
> nei confronti del destinatario o di terzi. ACTALIS S.p.A. non si 
> assume alcuna responsabilita' per eventuali intercettazioni, modifiche 
> o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> Any unauthorized use of this e-mail or any of its attachments is 
> prohibited and could constitute an offence. If you are not the 
> intended addressee please advise immediately the sender by using the 
> reply facility in your e-mail software and destroy the message and its 
> attachments. The statements and opinions expressed in this e-mail 
> message are those of the author of the message and do not necessarily 
> represent those of ACTALIS S.p.A. Besides, The contents of this 
> message shall be understood as neither given nor endorsed by ACTALIS 
> S.p.A.. ACTALIS S.p.A. does not accept liability for corruption, 
> interception or amendment, if any, or the consequences thereof.
> 
> 

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 1 Sep 2004 00:52:07 +0100

Thanks Steve for jumping in on this.

We completely agree on the facts of RFC 3280 path processing and I think
you showed this very well with support from the standard text.

We happen to disagree on the good or bad with processing root extensions
but I think we should save that to later :-)

Stefan Santesson
 
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be appropriate
for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to further
limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust anchor
during
>     the initialization phase, or the application MAY require the
presence
>     of a particular alternative name form in the end entity
certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm presented in
section
>     6.1 defines the minimum conditions for a path to be considered
valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose
> any additional requirements on paths that it likes (unless
> specifically prohibited by RFC 3280). This would include
> processing name constraints in trust anchors, pathLenConstraints
> in trust anchors, etc.
> 
> However, CAs who expect to act as trust anchors and issue
> self-signed certificates for that purpose should not assume
> that all path validation implementations will do this. If
> they REALLY want to ensure that path lengths are limited,
> they should certify a subsidiary CA and include a pathLen
> constraint in that certificate.
> 
> Now, there's a separate question about whether processing
> constraints in trust anchors is a good idea. I would argue
> that it's not. But that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> >
> > We could take extensions in the TA and use them to initialize a
> > certification path values permitted by 3280, but for values such as
path
> > length that 3280 does not permit initialization of to an arbitrary
> value, it
> > will require a change in the standard.
> >
> > From security viewpoint, I do not object to it, but it is a change
to
> the
> > standard.
> On
> > Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> >
> >>self-signed certificate of a trust anchor (root CA) should be
> > Unfortunately that is what X.509 has said for some time, and 3280
has
> > not deviated in this regard. I too was surprised by this initially.
> >
> > I discussed this issue with Sharon some time ago, noting that, for
> > example, one would like to impose name constraints through
> > configuration of trust anchors and the TA exception to the general
> > processing rules prohibits that.  So I agree completely that I would
> > like to see at least SOME of the constraints in a trust anchor cert
> > be applied to cert path processing, although one needs to carefully
> > examine the implications of doing this.
> >
> > BTW, Santosh is correct in noting that TAs are not literally certs,
> > even though self-signed certs are often used as a means of
> > representing TAs. However, since we admit that a TA can contain
> > parameters other than the TA name and key info, I think it is
> > reasonable to allow for the full range of extensions that might
> > appear in a CA cert, and to then use them (most of them?) to control
> > path processing.
> >
> > Steve
> >

Content-class: urn:content-classes:message
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Wed, 1 Sep 2004 00:52:07 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Thanks Steve for jumping in on this.

We completely agree on the facts of RFC 3280 path processing and I think
you showed this very well with support from the standard text.

We happen to disagree on the good or bad with processing root extensions
but I think we should save that to later :-)

Stefan Santesson
 
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be appropriate
for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to further
limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust anchor
during
>     the initialization phase, or the application MAY require the
presence
>     of a particular alternative name form in the end entity
certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm presented in
section
>     6.1 defines the minimum conditions for a path to be considered
valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose
> any additional requirements on paths that it likes (unless
> specifically prohibited by RFC 3280). This would include
> processing name constraints in trust anchors, pathLenConstraints
> in trust anchors, etc.
> 
> However, CAs who expect to act as trust anchors and issue
> self-signed certificates for that purpose should not assume
> that all path validation implementations will do this. If
> they REALLY want to ensure that path lengths are limited,
> they should certify a subsidiary CA and include a pathLen
> constraint in that certificate.
> 
> Now, there's a separate question about whether processing
> constraints in trust anchors is a good idea. I would argue
> that it's not. But that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> >
> > We could take extensions in the TA and use them to initialize a
> > certification path values permitted by 3280, but for values such as
path
> > length that 3280 does not permit initialization of to an arbitrary
> value, it
> > will require a change in the standard.
> >
> > From security viewpoint, I do not object to it, but it is a change
to
> the
> > standard.
> On
> > Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> >
> >>self-signed certificate of a trust anchor (root CA) should be
> > Unfortunately that is what X.509 has said for some time, and 3280
has
> > not deviated in this regard. I too was surprised by this initially.
> >
> > I discussed this issue with Sharon some time ago, noting that, for
> > example, one would like to impose name constraints through
> > configuration of trust anchors and the TA exception to the general
> > processing rules prohibits that.  So I agree completely that I would
> > like to see at least SOME of the constraints in a trust anchor cert
> > be applied to cert path processing, although one needs to carefully
> > examine the implications of doing this.
> >
> > BTW, Santosh is correct in noting that TAs are not literally certs,
> > even though self-signed certs are often used as a means of
> > representing TAs. However, since we admit that a TA can contain
> > parameters other than the TA name and key info, I think it is
> > reasonable to allow for the full range of extensions that might
> > appear in a CA cert, and to then use them (most of them?) to control
> > path processing.
> >
> > Steve
> >

Date: Tue, 31 Aug 2004 16:05:10 -0400
From: Steve Hanna <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: R: On cross-certificates and pathLenConstraint
Sender: [email-masked]

RFC 3280 says in section 6.1:

    A particular certification path may not, however, be appropriate for
    all applications.  Therefore, an application MAY augment this
    algorithm to further limit the set of valid paths.

and in section 6.2:

    An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

Therefore, I believe that path validation implementations
can go beyond the usual path validation algorithm to impose
any additional requirements on paths that it likes (unless
specifically prohibited by RFC 3280). This would include
processing name constraints in trust anchors, pathLenConstraints
in trust anchors, etc.

However, CAs who expect to act as trust anchors and issue
self-signed certificates for that purpose should not assume
that all path validation implementations will do this. If
they REALLY want to ensure that path lengths are limited,
they should certify a subsidiary CA and include a pathLen
constraint in that certificate.

Now, there's a separate question about whether processing
constraints in trust anchors is a good idea. I would argue
that it's not. But that's a topic for another email.

Thanks,

Steve

Santosh Chokhani wrote:

> Steve Kent:
> 
> We could take extensions in the TA and use them to initialize a
> certification path values permitted by 3280, but for values such as path
> length that 3280 does not permit initialization of to an arbitrary value, it
> will require a change in the standard.
> 
> From security viewpoint, I do not object to it, but it is a change to the
> standard.
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Kent
> Sent: Tuesday, August 31, 2004 9:51 AM
> To: Santoni Adriano
> Cc: [email-masked]
> Subject: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> 
>>self-signed certificate of a trust anchor (root CA) should be 
> Unfortunately that is what X.509 has said for some time, and 3280 has 
> not deviated in this regard. I too was surprised by this initially.
> 
> I discussed this issue with Sharon some time ago, noting that, for 
> example, one would like to impose name constraints through 
> configuration of trust anchors and the TA exception to the general 
> processing rules prohibits that.  So I agree completely that I would 
> like to see at least SOME of the constraints in a trust anchor cert 
> be applied to cert path processing, although one needs to carefully 
> examine the implications of doing this.
> 
> BTW, Santosh is correct in noting that TAs are not literally certs, 
> even though self-signed certs are often used as a means of 
> representing TAs. However, since we admit that a TA can contain 
> parameters other than the TA name and key info, I think it is 
> reasonable to allow for the full range of extensions that might 
> appear in a CA cert, and to then use them (most of them?) to control 
> path processing.
> 
> Steve
> 

Date: Tue, 31 Aug 2004 19:21:23 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Cc: [email-masked]
Sender: [email-masked]

>> 
> RFC 3280 allows you to augment the path validation algorithm in any way you want as long as it is further limiting trust.
> 
> Adjusting the max_path_length variable in accordance with a root is fully compliant with this.
> 
> Stefan Santesson

You don't necessarily need to augment the algorithm in any way to get this effect. Just take 'yourself' as trust anchor
and issue 'cross-certs' with whatever restrictions. 

Or, the other way around, anything that you would have created at intermediate steps
down in the validation algorithm should be usable as initial values. 

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 13:06:26 -0400
Sender: [email-masked]

Agreed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 11:17 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Sharon:

I agree that one is at liberty to take material from a trust anchor and use
to initialize the values for which X.509 and 3280 permit initialization.

However, part of this thread relates to basic constraints and path length.
For basic constraints, there is nothing to initialize.  X.509 and 3280 deal
with path length slightly differently (but in equivalent terms).  Thus, 3280
requires the value to be initialized from the length of the certification
path and X.509 initializes path depth to 1.  Thus, based on today's
standards, in neither case, you will take path length from the trust anchor
and initialize it.

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 10:45 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Sharon:

So, you agree with the following statements.  Right?

"The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard."

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 17:35:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

RFC 3280 allows you to augment the path validation algorithm in any way you want as long as it is further limiting trust.

Adjusting the max_path_length variable in accordance with a root is fully compliant with this.

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 31 augusti 2004 17:17
> To: [email-masked]
> Sharon:
> I agree that one is at liberty to take material from a trust anchor and
> use
> to initialize the values for which X.509 and 3280 permit initialization.
> 
> However, part of this thread relates to basic constraints and path length.
> For basic constraints, there is nothing to initialize.  X.509 and 3280
> deal
> with path length slightly differently (but in equivalent terms).  Thus,
> 3280
> requires the value to be initialized from the length of the certification
> path and X.509 initializes path depth to 1.  Thus, based on today's
> standards, in neither case, you will take path length from the trust
> anchor
> and initialize it.
> 
> 
> 
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 10:45 AM
> To: 'Santosh Chokhani'; [email-masked]
> I'm always afraid to just say yes, because of nuances in phrasing :-)
> 
> On the first statement I can just say yes I agree.
> 
> On the second statement, I need to be a little bit more precise. I would
> agree with the following "When you enforce constraints on the trust anchor
> certificate as part of certificate processing in path validation, that is
> not in compliance with the standard." However, if someone uses the
> relevant
> constraints in the trust anchor certificate to initialize the path
> validation variables or process constraints, then I would not say they
> were
> non-compliant because the standard doesn't impose any particular source
> for
> those variables values. That certificate is one possible source, but there
> are others as well.
> 
> Cheers,
> Sharon
> 
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Santosh Chokhani
> Sent: Tuesday, August 31, 2004 10:07 AM
> To: [email-masked]
> Sharon:
> So, you agree with the following statements.  Right?
> 
> "The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, that
> is
> not in compliance with the standard."
> 
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 9:57 AM
> To: 'Santosh Chokhani'; [email-masked]
> I just want to clarify that I absolutely agree that any extensions
> contained
> in a self-signed cert are NOT processed as part of path validation. The
> self
> signed cert is NOT part of the path that gets processed. It is a mechanism
> that MAY be used to convey the public key that is used to verify the
> signature on the first cert processed in the path.
> 
> What I was trying to explain earlier is that if a self-signed certificate
> is
> used to convey the public key of the CA that is the trust anchor to
> relying
> parties there may be some extensions in that self signed certificate.
> Because the self signed certificate is not part of the certification path,
> it does not get processed in path validation. However the standards say
> nothing about what other uses an implementor may decide to make of such
> extensions. The example I gave was where an implementor may decide to use
> those to ensure that a subordinate CA does not even issue certificates to
> other CAs. Another possible use would be, as Santosh describes, to use
> those
> values to configure the input variables to the path validation process
> (what
> I was referring to as process constraints). However, those are separate
> from
> path validation processing of certificates.
> 
> I also agree with Santosh that X.509 is moving in a direction that enables
> more variables to be inititalized (e.g. name constraints). However I don't
> expect any standards defining what implementors use to intitalize those
> values. In some cases it might be reasonable to use the extensions in a
> self
> signed certificate. In other cases there could be other sources
> (especially
> if there is a need to configure those input variables on a per user group,
> per user, per application or even per transaction basis).
> 
> Cheers,
> Sharon
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Santosh Chokhani
> Sent: Tuesday, August 31, 2004 7:47 AM
> To: [email-masked]
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, that
> is
> not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors extensions
> in
> the root and also permits most of the values to be initialized.  I know
> both
> X.509 and 3280 are moving towards the second one.  The first one can
> become
> a backward compatibility issue.
> 
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> I just want to add/clarify that I agree that discarding all extensions of
> root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present in
> roots but any present path length constraints, policy constraints,
> explicit
> policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to
> honour
> any constraints set in the root certificate so MS CAPIs decision to
> enforce
> ROOT extensions in this manner is not in conflict with RFC 3280, but you
> can't rely on that other RFC 3280 compliant implementations will do this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson

Date: Tue, 31 Aug 2004 12:25:03 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: RFC3280 Nits
Sender: [email-masked]

Here's two nits on RFC3280:

1. In 4.1.2.4 (Issuer) - the ASN.1 for NAME is

Name ::= CHOICE { RDNSequence }

but in the ASN.1 module it's:

Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }

2. Additionally in 4.1.2.4 it's

RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

While in the module it's:

RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue

Just want to make them the same.  I assume it ought to match what's in
the ASN.1 module.

Cheers - spt

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 12:19:31 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.

Accepting constraints configured in the applied root as input variables into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further constrain
trust.

Stefan Santesson

> Sent: den 31 augusti 2004 13:47
> To: [email-masked]
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate,
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors
> extensions in the root and also permits most of the values to be 
> initialized.  I know both
> X.509 and 3280 are moving towards the second one.  The first one can
> become
> a backward compatibility issue.
> 
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> I just want to add/clarify that I agree that discarding all extensions
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce
> ROOT extensions in this manner is not in conflict with RFC 3280, but you
> can't rely on that other RFC 3280 compliant implementations will do this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> > I thought it perfectly made sense to insert in a root CA certificate
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for 
> > example) to signify that that CA only issues certificates to 
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > >>To complicate matters further, if the trust anchor issues itself
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust
> > > >>model agnostic.
> > > >>
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>different values of pethLenConstraint down the chain); has
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati.
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>attachments. The statements and opinions expressed in this
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > > >>distruzione del messaggio stesso e dei suoi eventuali allegati.
> > > >>Le dichiarazioni contenute nel presente messaggio nonche' nei 
> > > >>suoi eventuali allegati devono essere attribuite esclusivamente
> > > al mittente
> > > >>ACTALIS S.p.A. non si assume alcuna responsabilita' per
> > > >>eventuali intercettazioni, modifiche o danneggiamenti del 
> > > >>presente
> > > messaggio e-mail.
> > > >>
> > > >>
> > > >>
> > > >>attachments. The statements and opinions expressed in this
> > > >>e-mail message are those of the author of the message and do not
> > > necessarily
> > per errore il presente messaggio, Le saremmo grati se ci inviasse, 
> > via e-mail, una comunicazione al riguardo e provvedesse nel contempo 
> > alla distruzione del messaggio stesso e dei suoi eventuali allegati. 
> > Le dichiarazioni contenute nel presente messaggio nonche' nei suoi 
> > eventuali allegati devono essere attribuite esclusivamente al 
> > mittente e non possono essere considerate come trasmesse o 
> > autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non 
> > impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
> > intercettazioni, modifiche o danneggiamenti del presente messaggio 
> > e-mail.
> >
> >
> >
> > reply facility in your e-mail software and destroy the message and 
> > its attachments. The statements and opinions expressed in this 
> > e-mail message are those of the author of the message and do not 
> > necessarily represent those of ACTALIS S.p.A. Besides, The contents 
> > of this message shall be understood as neither given nor endorsed by 
> > ACTALIS S.p.A.. ACTALIS S.p.A. does not accept liability for 
> > corruption, interception or amendment, if any, or the consequences 
> > thereof.
> >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:43:16 -0400
Importance: Normal
Sender: [email-masked]

Steve Kent:

We could take extensions in the TA and use them to initialize a
certification path values permitted by 3280, but for values such as path
length that 3280 does not permit initialization of to an arbitrary value, it
will require a change in the standard.

>From security viewpoint, I do not object to it, but it is a change to the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, August 31, 2004 9:51 AM
To: Santoni Adriano
Cc: [email-masked]
Subject: Re: R: On cross-certificates and pathLenConstraint

At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
>self-signed certificate of a trust anchor (root CA) should be 

Unfortunately that is what X.509 has said for some time, and 3280 has 
not deviated in this regard. I too was surprised by this initially.

I discussed this issue with Sharon some time ago, noting that, for 
example, one would like to impose name constraints through 
configuration of trust anchors and the TA exception to the general 
processing rules prohibits that.  So I agree completely that I would 
like to see at least SOME of the constraints in a trust anchor cert 
be applied to cert path processing, although one needs to carefully 
examine the implications of doing this.

BTW, Santosh is correct in noting that TAs are not literally certs, 
even though self-signed certs are often used as a means of 
representing TAs. However, since we admit that a TA can contain 
parameters other than the TA name and key info, I think it is 
reasonable to allow for the full range of extensions that might 
appear in a CA cert, and to then use them (most of them?) to control 
path processing.

Steve

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 16:31:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

You are right that you may provide trust information by means other than a certificate, but if you form a root certificate according to RFC 3280, then basic constraints MUST be present or the certificate is NOT RFC 3280 compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.

Accepting constraints configured in the applied root as input variables into the path processing is therefore completely allowed by RFC 3280 path processing as a way to augment the mandatory algorithm to further constrain trust.

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 31 augusti 2004 13:47
> To: [email-masked]
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, that
> is
> not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors extensions
> in
> the root and also permits most of the values to be initialized.  I know
> both
> X.509 and 3280 are moving towards the second one.  The first one can
> become
> a backward compatibility issue.
> 
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> I just want to add/clarify that I agree that discarding all extensions of
> root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present in
> roots but any present path length constraints, policy constraints,
> explicit
> policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to
> honour
> any constraints set in the root certificate so MS CAPIs decision to
> enforce
> ROOT extensions in this manner is not in conflict with RFC 3280, but you
> can't rely on that other RFC 3280 compliant implementations will do this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:17:20 -0400
Importance: Normal
Sender: [email-masked]

Sharon:

I agree that one is at liberty to take material from a trust anchor and use
to initialize the values for which X.509 and 3280 permit initialization.

However, part of this thread relates to basic constraints and path length.
For basic constraints, there is nothing to initialize.  X.509 and 3280 deal
with path length slightly differently (but in equivalent terms).  Thus, 3280
requires the value to be initialized from the length of the certification
path and X.509 initializes path depth to 1.  Thus, based on today's
standards, in neither case, you will take path length from the trust anchor
and initialize it.

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 10:45 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Sharon:

So, you agree with the following statements.  Right?

"The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard."

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 10:45:20 -0400
Sender: [email-masked]

I'm always afraid to just say yes, because of nuances in phrasing :-)

On the first statement I can just say yes I agree.

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 10:07 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Sharon:

So, you agree with the following statements.  Right?

"The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard."

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
From: Tom Gindin <[email-masked]>
Date: Tue, 31 Aug 2004 10:30:18 -0400
Sender: [email-masked]

        David:

        IMHO your suggestion is how path validation should work, as I 
stated in a discussion with Santosh a few months ago (
http://www.imc.org/ietf-pkix/mail-archive/msg02707.html).  Unfortunately, 
it is not how RFC 3280 6.1.2 k works - that initializes the maximum 
allowable length to the length of the path being tested.  Steve Hanna, in 
that same thread (http://www.imc.org/ietf-pkix/mail-archive/msg02717.html
), suggested that the first paragraph of 6.2 gave sufficient warrant to 
set the fields in the way I suggested in my posting if you want to, while 
still considering the validation algorithm 3280-compliant.  If you do that 
in your validation algorithm, it then becomes natural to honor 
NameConstraints and BasicConstraints from any v3 certificate which is 
being used to represent a trust anchor.  Of course, you can set the 
variables corresponding to those extensions from separate fields in your 
configuration database if you want to, or if you are using a v1 
certificate or bare public key to represent a trust anchor.
        Conditions on a trust anchor analogous to certificate extensions 
are natural.  What is IMO obscure is the meaning of the signature on a 
certificate being used to represent a trust anchor - the RP does not 
decide to trust or not trust the anchor based on that signature, but on 
its own independent judgment.

                Tom Gindin

"David P. Kemp" <[email-masked]>
Sent by: [email-masked]
08/30/2004 11:50 AM
 
        To:     [email-masked]
        cc: 

Santosh,

Because a self-signed certificate should appear only once at the
head of a path (and never elsewhere) the rule of "no extensions
in trust anchors" should apply only if "trust anchor" is defined
to be a public key that can be used to verify a certificate (self-signed
or otherwise).  It should not apply if the self-signed certificate itself
is defined to be the trust anchor.

Perhaps X.509 and RFC 3280 should be clarified to state that
there is no such thing as a "self signed root".  There are roots
(trust anchors) that are public keys only, and there are self
signed certificates that may be validated by a root and whose
extensions are to be honored.

Dave

Santosh Chokhani wrote:

>Stefan:
>
>I think extensions should be ignored in the trust anchor regardless of 
their
>criticality
>
>For reasons such as MS CAPI, it is best to keep the trust anchors to bear
>minimum required.
>
>If the Path Length constraint is present in the self signed root, it will 
be
>ignored by a X.509 and RFC 3280 compliant path validation implementation.
>
>However, there are implementations that honour Root extensions despite 
this
>and would thus honour Path length constraints present in roots. E.g. I 
know
>that MS CAPI will.
>
>Despite that, I would say that it is wrong to rely on critical extensions 
in
>root certificates since they are ignored in RFC 3280 path validation.
>
>Stefan Santesson
>>If CA A is simply another CA, CA B certificate can be validated as an 
>>If CA A is trust anchor, I think it can issue CA certificates.  I read 
>>both X.509 and 3280 to not enforce constraints in the trust anchor.
>>
>>BTW, all this discussion of hierarchies and cross certificates should 
>>pathLenConstraint=0, but I was referring to the pathLenConstraint in 
>>follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a 
>>foreign one) if the
>>self-issued certificate of CA A contains pathLenConstraint=0 ?
>>
>>However, those cross-certificates will only be trusted if paths are 
>>built to them that exclude the certificate that contains the path 
>>length constraint.
>>
>>CA A issues a cross certificate to CA B with a path length constraint 
>>However, users of CA D are able to trust certificates issued by CA C 
>>because the cross-certificate from D to B contains no such constraint.
>>
>>process paths including all the business controls. As for testing, I'd 
>>suggest you have a look at the PKITS test suite which tests all these 
>>In case of a "cross-certificate" (so to speak) issued by the same CA 
>>for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
>>allow the cross-certificate issuance regardless of the 
>>cross-certificate is "self-issued" and therefore, in a way, "out of 
>>scope" as far as the pathLenConstraint is concerned.
>>
>>However, in the case of a "real" cross-certificate, to be issued to 
>>another CA with a different name, it is not very clear to me if the
>>pathLenConstraint in CA1 affects the possibility of issuing a
>>By the way, I wonder how are the most widespread applications handling 
>>certificate chains containing cross-certs, in the various cases (e.g. 
>>Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei 
>>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio 
e-mail.
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. 
Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio 
e-mail.
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. 
Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>
>> 
>>
>
>
>
>
> 
>

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 10:07:22 -0400
Importance: Normal
Sender: [email-masked]

Sharon:

So, you agree with the following statements.  Right?

"The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard."

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 09:56:36 -0400
Sender: [email-masked]

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 7:47 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

Date: Tue, 31 Aug 2004 09:50:48 -0400
To: "Santoni Adriano" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: R: On cross-certificates and pathLenConstraint
Cc: <[email-masked]>
Sender: [email-masked]

At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
>self-signed certificate of a trust anchor (root CA) should be 

Unfortunately that is what X.509 has said for some time, and 3280 has 
not deviated in this regard. I too was surprised by this initially.

I discussed this issue with Sharon some time ago, noting that, for 
example, one would like to impose name constraints through 
configuration of trust anchors and the TA exception to the general 
processing rules prohibits that.  So I agree completely that I would 
like to see at least SOME of the constraints in a trust anchor cert 
be applied to cert path processing, although one needs to carefully 
examine the implications of doing this.

BTW, Santosh is correct in noting that TAs are not literally certs, 
even though self-signed certs are often used as a means of 
representing TAs. However, since we admit that a TA can contain 
parameters other than the TA name and key info, I think it is 
reasonable to allow for the full range of extensions that might 
appear in a CA cert, and to then use them (most of them?) to control 
path processing.

Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 07:47:15 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

The standard does NOT require basic constraints to be in the root.

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard.

I agree that a more flexible standard would be one that honors extensions in
the root and also permits most of the values to be initialized.  I know both
X.509 and 3280 are moving towards the second one.  The first one can become
a backward compatibility issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, August 31, 2004 6:26 AM
To: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santoni,

I just want to add/clarify that I agree that discarding all extensions of
root certificates in path processing is a bad design.

The result is as you conclude that Basic Constraints MUST be present in
roots but any present path length constraints, policy constraints, explicit
policies, name constraints etc, MAY be ignored.

However, as Sharon pointed out, it is not a violation of RFC 3280 to honour
any constraints set in the root certificate so MS CAPIs decision to enforce
ROOT extensions in this manner is not in conflict with RFC 3280, but you
can't rely on that other RFC 3280 compliant implementations will do this.
They may legitimately ignore this data.

Stefan Santesson

> trust anchor's self-signed certificate affect the certification path 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 07:42:55 -0400
Importance: Normal
Sender: [email-masked]

A trust anchor is not considered a certificate per X.509 and RFC 3280
regardless of what form it is promulgated in.  It could be a data structure
consisting of name, algorithm identifier, public key parameters, and public
key; it could be a self-signed certificate; or it could be a certificate. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Tuesday, August 31, 2004 3:26 AM
To: Peter Hesse; David P. Kemp
Cc: [email-masked]
Subject: R: On cross-certificates and pathLenConstraint

If I am getting you right, you are saying that the exensions in the
self-signed certificate of a trust anchor (root CA) should be ignored. This
is quite suprising to me!

I thought it perfectly made sense to insert in a root CA certificate a
basicConstraints with cA=TRUE and pathLenConstraint=0 (for example) to
signify that that CA only issues certificates to end-users and not to
subordinates. I am talking about the self-signed certificate used by an
autonomous CA to distribute its own public key in a way that allows easy
import into virtually all applications. [On the other hand, what CAs
distribute their own public keys as a bare public keys? Virtually none.]

It suddenly comes to my mind that perhaps the extensions in the root CA
certificates contained in the Windows store were inserted for the sole
purposes of accommodating MS CAPI idiosyncrasies (like mentioned by
Santesson) ...

It does not say "all CA certificates that are not trust anchors"; it says
"all CA certificates".

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per
conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

Thus I agree with Santosh that in no case should the extensions in a trust
anchor's self-signed certificate affect the certification path validation.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

> Because a self-signed certificate should appear only once at the head 
> of a path (and never elsewhere) the rule of "no extensions in trust 
> anchors" should apply only if "trust anchor" is defined to be a public 
> key that can be used to verify a certificate (self-signed or 
> otherwise).  It should not apply if the self-signed certificate itself 
> is defined to be the trust anchor.
> 
> Perhaps X.509 and RFC 3280 should be clarified to state that there is 
> no such thing as a "self signed root".  There are roots (trust 
> certificates that may be validated by a root and whose extensions are 
> to be honored.
> 
> Dave
> 
> 
> Santosh Chokhani wrote:
> 
> >Stefan:
> >
> >For reasons such as MS CAPI, it is best to keep the trust anchors to 
> >bear minimum required.
> >
> >If the Path Length constraint is present in the self signed root, it 
> >will be ignored by a X.509 and RFC 3280 compliant path
> >this and would thus honour Path length constraints present in roots. 
> >E.g. I know that MS CAPI will.
> >
> >>both X.509 and 3280 to not enforce constraints in the trust anchor.
> >>
> >>However, those cross-certificates will only be trusted if paths are 
> >>built to them that exclude the certificate that contains the path 
> >>length constraint.
> >>
> >>for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
> >>allow the cross-certificate issuance regardless of the 
> >>cross-certificate is "self-issued" and therefore, in a way, "out of 
> >>scope" as far as the pathLenConstraint is concerned.
> >>
> >>However, in the case of a "real" cross-certificate, to be issued to 
> >>another CA with a different name, it is not very clear to me if the 
> >>pathLenConstraint in CA1 affects the possibility of issuing a 
> >>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi
allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
comunicazione al riguardo e provvedesse nel contempo alla distruzione del
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
nel presente messaggio nonche' nei suoi eventuali allegati devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of ACTALIS S.p.A. Besides,
The contents of this message shall be understood as neither given nor
endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.

Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 12:48:29 +0200
Importance: normal
From: "Santoni Adriano" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>, "Peter Hesse" <[email-masked]>, "David P. Kemp" <[email-masked]>
Sender: [email-masked]

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: martedì 31 agosto 2004 12.26
A: Santoni Adriano; Peter Hesse; David P. Kemp
Cc: [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

Santoni,

Stefan Santesson

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 11:26:13 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santoni Adriano" <[email-masked]>, "Peter Hesse" <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Santoni,

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> If I am getting you right, you are saying that the exensions in the self-
> signed certificate of a trust anchor (root CA) should be ignored. This is
> quite suprising to me!
> 
> subordinates. I am talking about the self-signed certificate used by an
> autonomous CA to distribute its own public key in a way that allows easy
> import into virtually all applications.
> [On the other hand, what CAs distribute their own public keys as a bare
> public keys? Virtually none.]
> 
> It suddenly comes to my mind that perhaps the extensions in the root CA
> certificates contained in the Windows store were inserted for the sole
> purposes of accommodating MS CAPI idiosyncrasies (like mentioned by
> Santesson) ...
> 
> 	"...This extension MUST appear as a critical extension in all
> CA certificates
> It does not say "all CA certificates that are not trust anchors"; it says
> "all CA certificates".
> 
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di Peter Hesse
> Thus I agree with Santosh that in no case should the extensions in a trust
> anchor's self-signed certificate affect the certification path validation.
> 
> --Peter
> 
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> 
> > Is there ambiguity in the term trust anchor?  It seems
> > possible to regard the trust anchor as a bare public key or
> > as a certificate.
> >
> > Because a self-signed certificate should appear only once at
> > the head of a path (and never elsewhere) the rule of "no
> > extensions in trust anchors" should apply only if "trust
> > anchor" is defined to be a public key that can be used to
> > verify a certificate (self-signed or otherwise).  It should
> > not apply if the self-signed certificate itself is defined to
> > be the trust anchor.
> >
> > Perhaps X.509 and RFC 3280 should be clarified to state that
> > there is no such thing as a "self signed root".  There are
> > roots (trust anchors) that are public keys only, and there
> > are self signed certificates that may be validated by a root
> > and whose extensions are to be honored.
> >
> > Dave
> >
> >
> > Santosh Chokhani wrote:
> >
> > >Stefan:
> > >
> > >For reasons such as MS CAPI, it is best to keep the trust anchors to
> > >bear minimum required.
> > >
> > >If the Path Length constraint is present in the self signed root, it
> > >will be ignored by a X.509 and RFC 3280 compliant path
> > >this and would thus honour Path length constraints present in roots.
> > >E.g. I know that MS CAPI will.
> > >
> > >>both X.509 and 3280 to not enforce constraints in the trust anchor.
> > >>
> > >>However, those cross-certificates will only be trusted if paths are
> > >>built to them that exclude the certificate that contains the path
> > >>length constraint.
> > >>
> > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to to
> > >>allow the cross-certificate issuance regardless of the
> > >>cross-certificate is "self-issued" and therefore, in a way, "out of
> > >>scope" as far as the pathLenConstraint is concerned.
> > >>
> > >>However, in the case of a "real" cross-certificate, to be issued to
> > >>another CA with a different name, it is not very clear to me if the
> > >>pathLenConstraint in CA1 affects the possibility of issuing a
> > >>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto
> Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi
> allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore
> il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
> comunicazione al riguardo e provvedesse nel contempo alla distruzione del
> messaggio stesso e dei suoi eventuali allegati.
> Le dichiarazioni contenute nel presente messaggio nonche' nei suoi
> eventuali allegati devono essere attribuite esclusivamente al mittente e
> non possono essere considerate come trasmesse o autorizzate da ACTALIS
> S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei
> confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> prohibited and could constitute an offence. If you are not the intended
> addressee please advise immediately the sender by using the reply facility
> in your e-mail software and destroy the message and its attachments. The
> statements and opinions expressed in this e-mail message are those of the
> author of the message and do not necessarily represent those of ACTALIS
> S.p.A. Besides, The contents of this message shall be understood as
> neither given nor endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 

Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Tue, 31 Aug 2004 09:25:51 +0200
Importance: normal
From: "Santoni Adriano" <[email-masked]>
To: "Peter Hesse" <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

If I am getting you right, you are saying that the exensions in the self-signed certificate of a trust anchor (root CA) should be ignored. This is quite suprising to me!

I thought it perfectly made sense to insert in a root CA certificate a basicConstraints with cA=TRUE and pathLenConstraint=0 (for example) to signify that that CA only issues certificates to end-users and not to subordinates. I am talking about the self-signed certificate used by an autonomous CA to distribute its own public key in a way that allows easy import into virtually all applications.
[On the other hand, what CAs distribute their own public keys as a bare public keys? Virtually none.]

It suddenly comes to my mind that perhaps the extensions in the root CA certificates contained in the Windows store were inserted for the sole purposes of accommodating MS CAPI idiosyncrasies (like mentioned by Santesson) ...

However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
	"...This extension MUST appear as a critical extension in all CA certificates 
	that contain public keys used to validate digital signatures on certificates" ?

It does not say "all CA certificates that are not trust anchors"; it says "all CA certificates".

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

Thus I agree with Santosh that in no case should the extensions in a trust anchor's self-signed certificate affect the certification path validation.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

> Is there ambiguity in the term trust anchor?  It seems
> possible to regard the trust anchor as a bare public key or 
> as a certificate.
> 
> Because a self-signed certificate should appear only once at
> the head of a path (and never elsewhere) the rule of "no 
> extensions in trust anchors" should apply only if "trust 
> anchor" is defined to be a public key that can be used to 
> verify a certificate (self-signed or otherwise).  It should 
> not apply if the self-signed certificate itself is defined to 
> be the trust anchor.
> 
> Perhaps X.509 and RFC 3280 should be clarified to state that
> there is no such thing as a "self signed root".  There are 
> roots (trust anchors) that are public keys only, and there 
> are self signed certificates that may be validated by a root 
> and whose extensions are to be honored.
> 
> Dave
> 
> 
> Santosh Chokhani wrote:
> 
> >Stefan:
> >
> >For reasons such as MS CAPI, it is best to keep the trust anchors to
> >bear minimum required.
> >
> >If the Path Length constraint is present in the self signed root, it
> >will be ignored by a X.509 and RFC 3280 compliant path 
> >this and would thus honour Path length constraints present in roots.
> >E.g. I know that MS CAPI will.
> >
> >>both X.509 and 3280 to not enforce constraints in the trust anchor.
> >>
> >>However, those cross-certificates will only be trusted if paths are 
> >>built to them that exclude the certificate that contains the path 
> >>length constraint.
> >>
> >>for itself, to facilitate the CA key rollover, RFC 3280 seems to to
> >>allow the cross-certificate issuance regardless of the 
> >>cross-certificate is "self-issued" and therefore, in a way, "out of 
> >>scope" as far as the pathLenConstraint is concerned.
> >>
> >>However, in the case of a "real" cross-certificate, to be issued to
> >>another CA with a different name, it is not very clear to me if the 
> >>pathLenConstraint in CA1 affects the possibility of issuing a 
> >>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 22:54:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Yes that's true. That was not my question though :-) 

The question is: If we have an exception not to inhibit anyPolicy for
self issued certificates, since it only passes the policies from its
parent certificate, then why do we need to enforce inhibit anyPolicy
just because the self-issued certificate is last in a path.

Stefan Santesson

> Sent: den 30 augusti 2004 22:45
> To: [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Stefan:
> 
> For inhibit any policy, when you define skip certs, you want to
enforce
> the
> constraints on a specific CA down stream from you regardless of
whether
> the
> path is from your current certificate or from a current to roll over
> certificate.  Thus, skip certs for inhibit policy should not count
> self-issued certificates.
> 
> On
> Behalf Of Stefan Santesson
> Sent: Monday, August 30, 2004 12:42 PM
> To: Steve Hanna
> Cc: Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> 
> Thanks Steve,
> 
> Yes, this is a valid technical argument.
> I suppose it is reasonable to accept a certificate as a key rollover
cert
> despite name constraints violations in subjAltName while you wouldn't
> accept
> those violations if the same certificate was used as an EE cert to
> validate
> e.g. a new name constraints violating e-mail address of that CA.
> 
> It seems harder however to transfer this logic to inhibit anyPolicy.
Any
> ideas/arguments there?
> > On Behalf Of Steve Hanna
> > Sent: den 30 augusti 2004 17:07
> > To: Stefan Santesson
> > Cc: Sharon Boeyen; [email-masked]
> > Subject: Re: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> >
> > Stefan,
> >
> > You wrote:
> >  > For all valid paths to a self-issued certificate, the self-issued
> cert
> >  > will be preceded by a valid intermediary CA certificate with a  >
> > matching subject name. Lets call that the ICA cert.  >
> >  > It seams reasonable to me that that IF ICA has a valid subject
name
> >  > then that name would be OK also for the rollover cert, regardless
> of
> >  > whether it is used as an intermediary cert or validated as target
> > > cert.
> >
> > I will admit I had to check the archives on this one.
> > Your argument seemed compelling at first. But the email
> > below explains the problem. In a nutshell, the self-issued
certificate
> > can contain a *subjectAltName* that is not permitted by the name
> > constraints and not contained in the ICA cert.
> >
> > I hope that explains why this requirement is needed.
> >
> > Thanks,
> >
> > Steve
> >
> > -------- Original Message --------
> > Date: Fri, 04 May 2001 12:44:34 -0400
> > From: Steve Hanna <[email-masked]>
> > To: PKIX List <[email-masked]>
> > Subject: Ignoring name constraints with self-issued certs
> >
> > Regretfully, I must raise another issue with son-of-2459. In section
> > 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical.  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > This statement is consistent with the validation algorithm in
section
> > 6.1, which says:
> >
> >     A certificate is termed self-issued if the DNs that appear in
the
> >     subject and issuer fields are identical and are not empty.  In
> >     general, the issuer and subject of the certificates that make up
a
> >     path are different for each certificate.  However, a CA may
issue
> a
> >     certificate to itself to support key rollover or changes in
> >     certificate policies.  These self-issued certificates are not
> >     counted when evaluating path length or name constraints.
> >
> > However, these statements (and the corresponding text in the
> validation
> > algorithm, steps (b) and (c) of section 6.1.3) are not consistent
with
> > the text in X.509(2000), which says (in step g of section 10.5.1)
"If
> > the certificate is not an intermediate self-issued certificate,
check
> > that the subject name is within the name-space given by the value of
> > permitted-subtrees and is not within the name-space given by the
value
> > of excluded-subtrees."
> >
> > Note the word *intermediate* in X.509(2000). If a self-issued
> > certificate is the last certificate in the path, the name
constraints
> > check MUST be performed. Otherwise, a security hole is opened up.
> > Consider the following chain of 2 certificates:
> >
> > Certificate 1:
> >   Issuer:  o=trusty, c=us
> >   Subject: o=shady, c=us
> >   Basic Constraints:
> >    cA=true
> >   Name Constraints:
> >    Permitted:
> >     directoryName: o=shady, c=us
> >     rfc822Name: .shady.com
> >
> > Certificate 2:
> >   Issuer:  o=shady, c=us
> >   Subject: o=shady, c=us
> >   SubjectAltNames:
> >    rfc822Name: [email-masked]
> >
> > If o=trusty, c=us is one of the trust anchors (and the certificate
> > signatures verify), this chain is valid according to son-of-2459. It
> is
> > not valid according to X.509(2000). I think you will agree that the
> > behavior described in X.509(2000) is correct. Otherwise, self-issued
> > certificates can be used to completely bypass the effects of name
> > constraints.
> >
> > Therefore, I suggest that section 4.2.1.11 of
> > draft-ietf-pkix-new-part1-06.txt be modified to say:
> >
> >     Name constraints are not applied to certificates whose issuer
and
> >     subject are identical (unless the certificate is the final
> >     certificate in the path).  (This could prevent CAs that use name
> >     constraints from issuing self-signed certificates to implement
key
> >     rollover.)
> >
> > We should also modify the last sentence of the paragraph in section
> 6.1
> > that begins "A certificate is termed self-issued ..." (listed in
full
> > above) to "These self-issued certificates are not counted when
> > evaluating path length. Name constraints are only applied to a
> > self-issued certificate if it is the final certificate in the path."
> >
> > I also suggest that the start of steps (b) and (c) in section 6.1.3
be
> > changed to read:
> >
> >        (b) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is within one of the
> >        permitted_subtrees for X.500 distinguished names, and verify
> >        that each of the alternative names in the subjectAltName
> >        extension (critical or non-critical) is within one of the
> >        permitted_subtrees for that name type.
> >
> >        (c) If certificate i is self-issued and it is not the final
> >        certificate in the path, skip this step for certificate i.
> >        Otherwise, verify that the subject name is not within one of
> the
> >        excluded_subtrees for X.500 distinguished names, and verify
> that
> >        each of the alternative names in the subjectAltName extension
> >        (critical or non-critical) is not within one of the
> >        excluded_subtrees for that name type.
> >
> > Comments?
> >
> > Steve
> 
> 

Date: Mon, 30 Aug 2004 17:37:30 -0400
From: "David P. Kemp" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Santosh,

Yes, I agree.  I overlooked the paragraph that Peter pointed out; sorry 
for the confusion.

Dave

Santosh Chokhani wrote:

>David Kemp:
>
>I assume you are in agreement with me based on clarification by Peter Hesse?
>If not, I will be glad to respond.
>
>  
>

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 16:44:48 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

For inhibit any policy, when you define skip certs, you want to enforce the
constraints on a specific CA down stream from you regardless of whether the
path is from your current certificate or from a current to roll over
certificate.  Thus, skip certs for inhibit policy should not count
self-issued certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, August 30, 2004 12:42 PM
To: Steve Hanna
Cc: Sharon Boeyen; [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates

Thanks Steve,

Yes, this is a valid technical argument. 
I suppose it is reasonable to accept a certificate as a key rollover cert
despite name constraints violations in subjAltName while you wouldn't accept
those violations if the same certificate was used as an EE cert to validate
e.g. a new name constraints violating e-mail address of that CA.

It seems harder however to transfer this logic to inhibit anyPolicy. Any
ideas/arguments there? 

Stefan Santesson

> On Behalf Of Steve Hanna
> Sent: den 30 augusti 2004 17:07
> To: Stefan Santesson
> Cc: Sharon Boeyen; [email-masked]
> Subject: Re: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> 
> Stefan,
> 
> You wrote:
>  > For all valid paths to a self-issued certificate, the self-issued
cert
>  > will be preceded by a valid intermediary CA certificate with a  > 
> matching subject name. Lets call that the ICA cert.  >
>  > It seams reasonable to me that that IF ICA has a valid subject name
>  > then that name would be OK also for the rollover cert, regardless
of
>  > whether it is used as an intermediary cert or validated as target  
> > cert.
> 
> I will admit I had to check the archives on this one.
> Your argument seemed compelling at first. But the email
> below explains the problem. In a nutshell, the self-issued certificate 
> can contain a *subjectAltName* that is not permitted by the name 
> constraints and not contained in the ICA cert.
> 
> I hope that explains why this requirement is needed.
> 
> Thanks,
> 
> Steve
> 
> -------- Original Message --------
> Date: Fri, 04 May 2001 12:44:34 -0400
> From: Steve Hanna <[email-masked]>
> To: PKIX List <[email-masked]>
> Subject: Ignoring name constraints with self-issued certs
> 
> Regretfully, I must raise another issue with son-of-2459. In section 
> 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical.  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> This statement is consistent with the validation algorithm in section 
> 6.1, which says:
> 
>     A certificate is termed self-issued if the DNs that appear in the
>     subject and issuer fields are identical and are not empty.  In
>     general, the issuer and subject of the certificates that make up a
>     path are different for each certificate.  However, a CA may issue
a
>     certificate to itself to support key rollover or changes in
>     certificate policies.  These self-issued certificates are not
>     counted when evaluating path length or name constraints.
> 
> However, these statements (and the corresponding text in the
validation
> algorithm, steps (b) and (c) of section 6.1.3) are not consistent with 
> the text in X.509(2000), which says (in step g of section 10.5.1) "If 
> the certificate is not an intermediate self-issued certificate, check 
> that the subject name is within the name-space given by the value of 
> permitted-subtrees and is not within the name-space given by the value 
> of excluded-subtrees."
> 
> Note the word *intermediate* in X.509(2000). If a self-issued 
> certificate is the last certificate in the path, the name constraints 
> check MUST be performed. Otherwise, a security hole is opened up. 
> Consider the following chain of 2 certificates:
> 
> Certificate 1:
>   Issuer:  o=trusty, c=us
>   Subject: o=shady, c=us
>   Basic Constraints:
>    cA=true
>   Name Constraints:
>    Permitted:
>     directoryName: o=shady, c=us
>     rfc822Name: .shady.com
> 
> Certificate 2:
>   Issuer:  o=shady, c=us
>   Subject: o=shady, c=us
>   SubjectAltNames:
>    rfc822Name: [email-masked]
> 
> If o=trusty, c=us is one of the trust anchors (and the certificate 
> signatures verify), this chain is valid according to son-of-2459. It
is
> not valid according to X.509(2000). I think you will agree that the 
> behavior described in X.509(2000) is correct. Otherwise, self-issued 
> certificates can be used to completely bypass the effects of name 
> constraints.
> 
> Therefore, I suggest that section 4.2.1.11 of 
> draft-ietf-pkix-new-part1-06.txt be modified to say:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical (unless the certificate is the final
>     certificate in the path).  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> We should also modify the last sentence of the paragraph in section
6.1
> that begins "A certificate is termed self-issued ..." (listed in full
> above) to "These self-issued certificates are not counted when 
> evaluating path length. Name constraints are only applied to a 
> self-issued certificate if it is the final certificate in the path."
> 
> I also suggest that the start of steps (b) and (c) in section 6.1.3 be 
> changed to read:
> 
>        (b) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is within one of the
>        permitted_subtrees for X.500 distinguished names, and verify
>        that each of the alternative names in the subjectAltName
>        extension (critical or non-critical) is within one of the
>        permitted_subtrees for that name type.
> 
>        (c) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is not within one of
the
>        excluded_subtrees for X.500 distinguished names, and verify
that
>        each of the alternative names in the subjectAltName extension
>        (critical or non-critical) is not within one of the
>        excluded_subtrees for that name type.
> 
> Comments?
> 
> Steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 16:17:34 -0400
Importance: Normal
Sender: [email-masked]

David Kemp:

I assume you are in agreement with me based on clarification by Peter Hesse?
If not, I will be glad to respond.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Monday, August 30, 2004 11:51 AM
To: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint

Santosh,

Is there ambiguity in the term trust anchor?  It seems possible to regard
the trust anchor as a bare public key or as a certificate.

Because a self-signed certificate should appear only once at the head of a
path (and never elsewhere) the rule of "no extensions in trust anchors"
should apply only if "trust anchor" is defined to be a public key that can
be used to verify a certificate (self-signed or otherwise).  It should not
apply if the self-signed certificate itself is defined to be the trust
anchor.

Perhaps X.509 and RFC 3280 should be clarified to state that there is no
such thing as a "self signed root".  There are roots (trust anchors) that
are public keys only, and there are self signed certificates that may be
validated by a root and whose extensions are to be honored.

Dave

Santosh Chokhani wrote:

>Stefan:
>
>I think extensions should be ignored in the trust anchor regardless of 
>their criticality
>
>For reasons such as MS CAPI, it is best to keep the trust anchors to 
>bear minimum required.
>
>If the Path Length constraint is present in the self signed root, it 
>will be ignored by a X.509 and RFC 3280 compliant path validation 
>implementation.
>
>However, there are implementations that honour Root extensions despite 
>this and would thus honour Path length constraints present in roots. 
>E.g. I know that MS CAPI will.
>
>extensions in root certificates since they are ignored in RFC 3280 path 
>validation.
>
>Stefan Santesson
>>If CA A is simply another CA, CA B certificate can be validated as an
>>If CA A is trust anchor, I think it can issue CA certificates.  I read
>>both X.509 and 3280 to not enforce constraints in the trust anchor.
>>
>>BTW, all this discussion of hierarchies and cross certificates should
>>pathLenConstraint=0, but I was referring to the pathLenConstraint in 
>>follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a 
>>foreign one) if the
>>self-issued certificate of CA A contains pathLenConstraint=0 ?
>>
>>However, those cross-certificates will only be trusted if paths are 
>>built to them that exclude the certificate that contains the path 
>>length constraint.
>>
>>CA A issues a cross certificate to CA B with a path length constraint
>>However, users of CA D are able to trust certificates issued by CA C
>>because the cross-certificate from D to B contains no such constraint.
>>
>>process paths including all the business controls. As for testing, I'd 
>>suggest you have a look at the PKITS test suite which tests all these 
>>In case of a "cross-certificate" (so to speak) issued by the same CA
>>for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
>>allow the cross-certificate issuance regardless of the 
>>cross-certificate is "self-issued" and therefore, in a way, "out of 
>>scope" as far as the pathLenConstraint is concerned.
>>
>>However, in the case of a "real" cross-certificate, to be issued to
>>another CA with a different name, it is not very clear to me if the
>>pathLenConstraint in CA1 affects the possibility of issuing a
>>By the way, I wonder how are the most widespread applications handling
>>certificate chains containing cross-certs, in the various cases (e.g. 
>>Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei
>>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
>>
>>
>>
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
>>
>>
>>
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>
>>    
>>
>
>
>
>
>  
>

From: "Peter Hesse" <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 12:42:39 -0400
Sender: [email-masked]

Thus I agree with Santosh that in no case should the extensions in a trust
anchor's self-signed certificate affect the certification path validation.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

> Is there ambiguity in the term trust anchor?  It seems 
> possible to regard the trust anchor as a bare public key or 
> as a certificate.
> 
> Because a self-signed certificate should appear only once at 
> the head of a path (and never elsewhere) the rule of "no 
> extensions in trust anchors" should apply only if "trust 
> anchor" is defined to be a public key that can be used to 
> verify a certificate (self-signed or otherwise).  It should 
> not apply if the self-signed certificate itself is defined to 
> be the trust anchor.
> 
> Perhaps X.509 and RFC 3280 should be clarified to state that 
> there is no such thing as a "self signed root".  There are 
> roots (trust anchors) that are public keys only, and there 
> are self signed certificates that may be validated by a root 
> and whose extensions are to be honored.
> 
> Dave
> 
> 
> Santosh Chokhani wrote:
> 
> >Stefan:
> >
> >For reasons such as MS CAPI, it is best to keep the trust anchors to 
> >bear minimum required.
> >
> >If the Path Length constraint is present in the self signed root, it 
> >will be ignored by a X.509 and RFC 3280 compliant path 
> >this and would thus honour Path length constraints present in roots. 
> >E.g. I know that MS CAPI will.
> >
> >>both X.509 and 3280 to not enforce constraints in the trust anchor.
> >>
> >>However, those cross-certificates will only be trusted if paths are 
> >>built to them that exclude the certificate that contains the path 
> >>length constraint.
> >>
> >>for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
> >>allow the cross-certificate issuance regardless of the 
> >>cross-certificate is "self-issued" and therefore, in a way, "out of 
> >>scope" as far as the pathLenConstraint is concerned.
> >>
> >>However, in the case of a "real" cross-certificate, to be issued to 
> >>another CA with a different name, it is not very clear to me if the 
> >>pathLenConstraint in CA1 affects the possibility of issuing a 
> >>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 17:41:31 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Steve Hanna" <[email-masked]>
Cc: "Sharon Boeyen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Thanks Steve,

Yes, this is a valid technical argument. 
I suppose it is reasonable to accept a certificate as a key rollover
cert despite name constraints violations in subjAltName while you
wouldn't accept those violations if the same certificate was used as an
EE cert to validate e.g. a new name constraints violating e-mail address
of that CA.

It seems harder however to transfer this logic to inhibit anyPolicy. Any
ideas/arguments there? 

Stefan Santesson

> On Behalf Of Steve Hanna
> Sent: den 30 augusti 2004 17:07
> To: Stefan Santesson
> Cc: Sharon Boeyen; [email-masked]
> Subject: Re: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Stefan,
> 
> You wrote:
>  > For all valid paths to a self-issued certificate, the self-issued
cert
>  > will be preceded by a valid intermediary CA certificate with a
>  > matching subject name. Lets call that the ICA cert.
>  >
>  > It seams reasonable to me that that IF ICA has a valid subject name
>  > then that name would be OK also for the rollover cert, regardless
of
>  > whether it is used as an intermediary cert or validated as target
>  > cert.
> 
> I will admit I had to check the archives on this one.
> Your argument seemed compelling at first. But the email
> below explains the problem. In a nutshell, the self-issued
> certificate can contain a *subjectAltName* that is not
> permitted by the name constraints and not contained in
> the ICA cert.
> 
> I hope that explains why this requirement is needed.
> 
> Thanks,
> 
> Steve
> 
> -------- Original Message --------
> Date: Fri, 04 May 2001 12:44:34 -0400
> From: Steve Hanna <[email-masked]>
> To: PKIX List <[email-masked]>
> Subject: Ignoring name constraints with self-issued certs
> 
> Regretfully, I must raise another issue with son-of-2459. In section
> 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical.  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> This statement is consistent with the validation algorithm in section
> 6.1, which says:
> 
>     A certificate is termed self-issued if the DNs that appear in the
>     subject and issuer fields are identical and are not empty.  In
>     general, the issuer and subject of the certificates that make up a
>     path are different for each certificate.  However, a CA may issue
a
>     certificate to itself to support key rollover or changes in
>     certificate policies.  These self-issued certificates are not
>     counted when evaluating path length or name constraints.
> 
> However, these statements (and the corresponding text in the
validation
> algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
> the text in X.509(2000), which says (in step g of section 10.5.1) "If
> the certificate is not an intermediate self-issued certificate, check
> that the subject name is within the name-space given by the value of
> permitted-subtrees and is not within the name-space given by the value
> of excluded-subtrees."
> 
> Note the word *intermediate* in X.509(2000). If a self-issued
> certificate is the last certificate in the path, the name constraints
> check MUST be performed. Otherwise, a security hole is opened up.
> Consider the following chain of 2 certificates:
> 
> Certificate 1:
>   Issuer:  o=trusty, c=us
>   Subject: o=shady, c=us
>   Basic Constraints:
>    cA=true
>   Name Constraints:
>    Permitted:
>     directoryName: o=shady, c=us
>     rfc822Name: .shady.com
> 
> Certificate 2:
>   Issuer:  o=shady, c=us
>   Subject: o=shady, c=us
>   SubjectAltNames:
>    rfc822Name: [email-masked]
> 
> If o=trusty, c=us is one of the trust anchors (and the certificate
> signatures verify), this chain is valid according to son-of-2459. It
is
> not valid according to X.509(2000). I think you will agree that the
> behavior described in X.509(2000) is correct. Otherwise, self-issued
> certificates can be used to completely bypass the effects of name
> constraints.
> 
> Therefore, I suggest that section 4.2.1.11 of
> draft-ietf-pkix-new-part1-06.txt be modified to say:
> 
>     Name constraints are not applied to certificates whose issuer and
>     subject are identical (unless the certificate is the final
>     certificate in the path).  (This could prevent CAs that use name
>     constraints from issuing self-signed certificates to implement key
>     rollover.)
> 
> We should also modify the last sentence of the paragraph in section
6.1
> that begins "A certificate is termed self-issued ..." (listed in full
> above) to "These self-issued certificates are not counted when
> evaluating path length. Name constraints are only applied to a
> self-issued certificate if it is the final certificate in the path."
> 
> I also suggest that the start of steps (b) and (c) in section 6.1.3 be
> changed to read:
> 
>        (b) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is within one of the
>        permitted_subtrees for X.500 distinguished names, and verify
>        that each of the alternative names in the subjectAltName
>        extension (critical or non-critical) is within one of the
>        permitted_subtrees for that name type.
> 
>        (c) If certificate i is self-issued and it is not the final
>        certificate in the path, skip this step for certificate i.
>        Otherwise, verify that the subject name is not within one of
the
>        excluded_subtrees for X.500 distinguished names, and verify
that
>        each of the alternative names in the subjectAltName extension
>        (critical or non-critical) is not within one of the
>        excluded_subtrees for that name type.
> 
> Comments?
> 
> Steve

Date: Mon, 30 Aug 2004 11:50:36 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: On cross-certificates and pathLenConstraint
Sender: [email-masked]

Santosh,

Because a self-signed certificate should appear only once at the
head of a path (and never elsewhere) the rule of "no extensions
in trust anchors" should apply only if "trust anchor" is defined
to be a public key that can be used to verify a certificate (self-signed
or otherwise).  It should not apply if the self-signed certificate itself
is defined to be the trust anchor.

Perhaps X.509 and RFC 3280 should be clarified to state that
there is no such thing as a "self signed root".  There are roots
(trust anchors) that are public keys only, and there are self
signed certificates that may be validated by a root and whose
extensions are to be honored.

Dave

Santosh Chokhani wrote:

>Stefan:
>
>I think extensions should be ignored in the trust anchor regardless of their
>criticality
>
>For reasons such as MS CAPI, it is best to keep the trust anchors to bear
>minimum required.
>
>If the Path Length constraint is present in the self signed root, it will be
>ignored by a X.509 and RFC 3280 compliant path validation implementation.
>
>However, there are implementations that honour Root extensions despite this
>and would thus honour Path length constraints present in roots. E.g. I know
>that MS CAPI will.
>
>Despite that, I would say that it is wrong to rely on critical extensions in
>root certificates since they are ignored in RFC 3280 path validation.
>
>Stefan Santesson
>>If CA A is simply another CA, CA B certificate can be validated as an 
>>If CA A is trust anchor, I think it can issue CA certificates.  I read 
>>both X.509 and 3280 to not enforce constraints in the trust anchor.
>>
>>BTW, all this discussion of hierarchies and cross certificates should 
>>pathLenConstraint=0, but I was referring to the pathLenConstraint in 
>>follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a 
>>foreign one) if the
>>self-issued certificate of CA A contains pathLenConstraint=0 ?
>>
>>However, those cross-certificates will only be trusted if paths are 
>>built to them that exclude the certificate that contains the path 
>>length constraint.
>>
>>CA A issues a cross certificate to CA B with a path length constraint 
>>However, users of CA D are able to trust certificates issued by CA C 
>>because the cross-certificate from D to B contains no such constraint.
>>
>>process paths including all the business controls. As for testing, I'd 
>>suggest you have a look at the PKITS test suite which tests all these 
>>In case of a "cross-certificate" (so to speak) issued by the same CA 
>>for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
>>allow the cross-certificate issuance regardless of the 
>>cross-certificate is "self-issued" and therefore, in a way, "out of 
>>scope" as far as the pathLenConstraint is concerned.
>>
>>However, in the case of a "real" cross-certificate, to be issued to 
>>another CA with a different name, it is not very clear to me if the
>>pathLenConstraint in CA1 affects the possibility of issuing a
>>By the way, I wonder how are the most widespread applications handling 
>>certificate chains containing cross-certs, in the various cases (e.g. 
>>Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei 
>>suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
>>
>>
>>
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>e non possono essere considerate come
>>trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
>>impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
>>intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
>>
>>
>>
>>attachments. The statements
>>and opinions expressed in this e-mail message are those of the author of
>>the
>>message and do not necessarily represent those of ACTALIS S.p.A. Besides,
>>The contents of this message shall be understood as neither given nor
>>endorsed by ACTALIS S.p.A..
>>ACTALIS S.p.A. does not accept liability for corruption, interception or
>>amendment, if any, or the consequences thereof.
>>
>>
>>
>>    
>>
>
>
>
>
>  
>

Date: Mon, 30 Aug 2004 11:07:00 -0400
From: Steve Hanna <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Sharon Boeyen <[email-masked]>, [email-masked]
Subject: Re: RFC 3280 bug? - Special processing for self issued certificates
Sender: [email-masked]

Stefan,

You wrote:
 > For all valid paths to a self-issued certificate, the self-issued cert
 > will be preceded by a valid intermediary CA certificate with a
 > matching subject name. Lets call that the ICA cert.
 >
 > It seams reasonable to me that that IF ICA has a valid subject name
 > then that name would be OK also for the rollover cert, regardless of
 > whether it is used as an intermediary cert or validated as target
 > cert.

I will admit I had to check the archives on this one.
Your argument seemed compelling at first. But the email
below explains the problem. In a nutshell, the self-issued
certificate can contain a *subjectAltName* that is not
permitted by the name constraints and not contained in
the ICA cert.

I hope that explains why this requirement is needed.

Thanks,

Steve

-------- Original Message --------
Date: Fri, 04 May 2001 12:44:34 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Ignoring name constraints with self-issued certs

Regretfully, I must raise another issue with son-of-2459. In section
4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says:

    Name constraints are not applied to certificates whose issuer and
    subject are identical.  (This could prevent CAs that use name
    constraints from issuing self-signed certificates to implement key
    rollover.)

This statement is consistent with the validation algorithm in section
6.1, which says:

    A certificate is termed self-issued if the DNs that appear in the
    subject and issuer fields are identical and are not empty.  In
    general, the issuer and subject of the certificates that make up a
    path are different for each certificate.  However, a CA may issue a
    certificate to itself to support key rollover or changes in
    certificate policies.  These self-issued certificates are not
    counted when evaluating path length or name constraints.

However, these statements (and the corresponding text in the validation
algorithm, steps (b) and (c) of section 6.1.3) are not consistent with
the text in X.509(2000), which says (in step g of section 10.5.1) "If
the certificate is not an intermediate self-issued certificate, check
that the subject name is within the name-space given by the value of
permitted-subtrees and is not within the name-space given by the value
of excluded-subtrees."

Note the word *intermediate* in X.509(2000). If a self-issued
certificate is the last certificate in the path, the name constraints
check MUST be performed. Otherwise, a security hole is opened up.
Consider the following chain of 2 certificates:

Certificate 1:
  Issuer:  o=trusty, c=us
  Subject: o=shady, c=us
  Basic Constraints:
   cA=true
  Name Constraints:
   Permitted:
    directoryName: o=shady, c=us
    rfc822Name: .shady.com

Certificate 2:
  Issuer:  o=shady, c=us
  Subject: o=shady, c=us
  SubjectAltNames:
   rfc822Name: [email-masked]

If o=trusty, c=us is one of the trust anchors (and the certificate
signatures verify), this chain is valid according to son-of-2459. It is
not valid according to X.509(2000). I think you will agree that the
behavior described in X.509(2000) is correct. Otherwise, self-issued
certificates can be used to completely bypass the effects of name
constraints.

Therefore, I suggest that section 4.2.1.11 of
draft-ietf-pkix-new-part1-06.txt be modified to say:

    Name constraints are not applied to certificates whose issuer and
    subject are identical (unless the certificate is the final
    certificate in the path).  (This could prevent CAs that use name
    constraints from issuing self-signed certificates to implement key
    rollover.)

We should also modify the last sentence of the paragraph in section 6.1
that begins "A certificate is termed self-issued ..." (listed in full
above) to "These self-issued certificates are not counted when
evaluating path length. Name constraints are only applied to a
self-issued certificate if it is the final certificate in the path."

I also suggest that the start of steps (b) and (c) in section 6.1.3 be
changed to read:

       (b) If certificate i is self-issued and it is not the final
       certificate in the path, skip this step for certificate i.
       Otherwise, verify that the subject name is within one of the
       permitted_subtrees for X.500 distinguished names, and verify
       that each of the alternative names in the subjectAltName
       extension (critical or non-critical) is within one of the
       permitted_subtrees for that name type.

       (c) If certificate i is self-issued and it is not the final
       certificate in the path, skip this step for certificate i.
       Otherwise, verify that the subject name is not within one of the
       excluded_subtrees for X.500 distinguished names, and verify that
       each of the alternative names in the subjectAltName extension
       (critical or non-critical) is not within one of the
       excluded_subtrees for that name type.

Comments?

Steve

From: Sharon Boeyen <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Mon, 30 Aug 2004 10:49:53 -0400
Sender: [email-masked]

Getting back to Adriano's question:

Neither X.509 nor RFC 3280 use certificate extensions to control what
certificates can be issued by other CAs, but rather they both use the
extensions to control what certificates RPs trust. 

Dealing with path validation, if basicConstraints extension is included in a
self-signed certificate with a path length of 0, RPs will ignore that path
length constraint when the do path validation. 

However, dealing with certificate issuance, there would be nothing wrong
with using that path length constraint as a tool to help enforce the
domain's security policy, which in your example would mean that other CA's
shouldn't be issuing certificates to other CAs, but only to users. However,
beware that this is definitely not required by standards so relying on it in
any particular environment could be risky (different vendors may possibly
use different techniques to control the privileges CAs have when issuing
certificates). X.509 includes no such requirements, but focuses instead on
ensuring that only certificates that are intended to be trusted will
actually be trusted. 

Hope that helps rather than further confuses the issue :-)

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Saturday, August 28, 2004 8:27 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Stefan:

I think extensions should be ignored in the trust anchor regardless of their
criticality

For reasons such as MS CAPI, it is best to keep the trust anchors to bear
minimum required.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Saturday, August 28, 2004 5:10 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

If the Path Length constraint is present in the self signed root, it will be
ignored by a X.509 and RFC 3280 compliant path validation implementation.

However, there are implementations that honour Root extensions despite this
and would thus honour Path length constraints present in roots. E.g. I know
that MS CAPI will.

Despite that, I would say that it is wrong to rely on critical extensions in
root certificates since they are ignored in RFC 3280 path validation.

Stefan Santesson

> If CA A is simply another CA, CA B certificate can be validated as an
> If CA A is trust anchor, I think it can issue CA certificates.  I read
> both X.509 and 3280 to not enforce constraints in the trust anchor.
> 
> BTW, all this discussion of hierarchies and cross certificates should
> pathLenConstraint=0, but I was referring to the pathLenConstraint in 
> follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a 
> foreign one) if the
> self-issued certificate of CA A contains pathLenConstraint=0 ?
> 
> However, those cross-certificates will only be trusted if paths are 
> built to them that exclude the certificate that contains the path 
> length constraint.
> 
> CA A issues a cross certificate to CA B with a path length constraint
> However, users of CA D are able to trust certificates issued by CA C
> because the cross-certificate from D to B contains no such constraint.
> 
> process paths including all the business controls. As for testing, I'd 
> suggest you have a look at the PKITS test suite which tests all these 
> In case of a "cross-certificate" (so to speak) issued by the same CA
> for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
> allow the cross-certificate issuance regardless of the 
> cross-certificate is "self-issued" and therefore, in a way, "out of 
> scope" as far as the pathLenConstraint is concerned.
> 
> However, in the case of a "real" cross-certificate, to be issued to
> another CA with a different name, it is not very clear to me if the
> pathLenConstraint in CA1 affects the possibility of issuing a
> By the way, I wonder how are the most widespread applications handling
> certificate chains containing cross-certs, in the various cases (e.g. 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei
> suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 
> e non possono essere considerate come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> attachments. The statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> e non possono essere considerate come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> attachments. The statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> 

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Sharon Boeyen <[email-masked]>, [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Mon, 30 Aug 2004 10:36:02 -0400
Sender: [email-masked]

I don't see a problem with the certificate validating differently in
different contexts. This happens all the time with target certificates if
client side setting of business controls is used (I like to call these
'process controls' as opposed to 'infrastructure controls' which is the term
I like to use for business controls placed in certificates). With the
identical certification path a certificate may pass validation in one
context (e.g. if the client side settings impose a policy related control
for one validation event but not for another). The process constraints could
be set different by the same RP for different applications, different
transactions, different physical environments etc. While I agree that this
is slightly different than the case you are describing because you aren't
using process constraints, I just wanted to provide an example of where the
same cert can have different results depending on the context in which it is
being validated. Therefore I don't see what you are describing as a problem
from that perspective.

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, August 27, 2004 12:54 PM
To: Sharon Boeyen; [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates

Well,

That doesn't really help. What you say is what I assumed is the case.

However, I don't see any real threats avoided with the current approach,
only problems.

The only aspects that are influenced by this logic are name constraints and
processing anyPolicy when inhibited. I have tried to think hard here but I
can't see any real threats avoided by the current logic.

For all valid paths to a self-issued certificate, the self-issued cert will
be preceded by a valid intermediary CA certificate with a matching subject
name. Lets call that the ICA cert.

It seams reasonable to me that that IF ICA has a valid subject name then
that name would be OK also for the rollover cert, regardless of whether it
is used as an intermediary cert or validated as target cert.

Likewise, if ICA is valid for a certain set of policies, then those policies
would also be good for the rollover cert, regardless of whether it is used
as an intermediary cert or validated as target cert.

I just don't see the threat NOR the real benefit.

The problem that I sense (if this is a problem at all) is that the same
certificate placed under the same certificate path, may be both valid and
invalid at the same time, depending on the context within which you examine
it.

An example:

You look at the certificate path in a viewer and see the complete path as
valid. Then you click on the rollover cert to take a closer look at it and
suddenly that cert shows as invalid. It shows as invalid because when you
take a look just at this cert, it is now at the end of a path and can't be
validated.

Do you see the problem or are my worries completely false here. I want to
know whether I just see ghosts.

Stefan Santesson

> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> I tried to address that at the end of my email but probably didn't do
a
> very
> good job of it. The reason for making the exceptions was primarily so
that
> CA key rollover didn't interfere with business controls for path 
> processing. However, if the self-issued certificate is the final 
> certificate in
the
> path
> then it should no longer get excepted because it is now the target of
the
> path validation and therefore the constraints should apply to it. In
the
> intermediate case the certificate's existence is most likely not even 
> known to the RP. If it is the target cert however, then it is most
definitely
> known to the RP and any business controls, whether imposed directly by
the
> RP through initializing settings for the path validation variables or
by
> CAs
> in cross certs should apply.
> 
> Does that help at all?
> 
> Cheers,
> Sharon
> 
> Sent: Friday, August 27, 2004 10:01 AM
> To: Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> 
> Sharon,
> 
> I think you misread my question/issue.
> 
> I do not question why self-issued certs are excepted from path length 
> counting or anyPolicy inhabitation.
> 
> My question is why some exceptions for processing self-issued
certificates
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> different if the self-issued certificate is intermediate or the last 
> certificate in the path.
> 
> 
> Stefan Santesson
> > From: Sharon Boeyen [mailto:[email-masked]]
> > Sent: den 27 augusti 2004 14:56
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: RFC 3280 bug? - Special processing for self issued 
> > certificates
> >
> > Hi Stefan,
> >
> > The reason for the exception cases for self-issued intermediate 
> > certificates deals mainly with their role in a CA key rollover 
> > situation. In this situation, the fact that a CA has rolled its key, 
> > should not change
> the
> > processing of a path. For example if a path length constraint of 3
is
> ok
> > before the rollover that same path length constraint should be ok
with
> the
> > self-issued intermediate cert that perfoms the key rollover. Similar
> logic
> > applies to the anyPolicy and to name constraints. From an X.509 
> > perspective, note that the anyPolicy situation was handled by DR
276.
> > FYI, here is
> just
> > the rationale piece of that DR. You can check its processing via the 
> > regular docs on Hoyt's server. I could look up the DTC TC numbers if 
> > you need them. DR 273 addressed the name constraints issues in this 
> > area. Some of
the
> > other
> > areas, such as basic constraints, were addressed in the 4th edition
> text.
> >
> > Rationale text from DR 276:
> > ---------------------
> > One use of self-issued certificates is for a CA to roll over its 
> > certificate and/or CRL signing keys without disruption to 
> > certification paths that were previously established. In such cases 
> > it is convenient for the CA to include
> > the special value anyPolicy in the certificate policies extension of
> the
> > self-issued certificate. This allows the self-issued certificate to 
> > provide a link in certification paths for any policy that would be 
> > valid if
> the
> > self-issued certificate did not exist. However, there is a problem
if
> the
> > inhibit-any-policy-indicator is set in the certification path
> processing
> > procedure prior to a self-issued certificate. The current text would 
> > result in failure of the path because of the existence of anyPolicy
in
> > the self-issued certificate. However, if the self-issued certificate 
> > did
> not
> > exist (i.e. the CA had not yet rolled over its key), paths for which 
> > specific policies are present in all subsequent certificates may
have
> > passed, but will always fail due to anyPolicy in the self-issued 
> > certificate.
> > ---------------------
> > That particular DR was accepted (along with other related ones and 
> > original non-defect changes in the 2000 text)
> >
> > These exceptions applied only to intermediate self issued certs
> because
> > the
> > exceptions are to allow paths to have the same result in these areas 
> > regardless of whether or not one or more CAs in the path had
undergone
> a
> > key
> > rollover. However, if the end certificate happens to be a
self-issued
> > certificate, the exceptions do not apply because that is the
> certificate
> > that is the one of interest. Therefore if any constraints preclude
> that
> > certificate, it cannot be considered valid.
> >
> > Cheers,
> > Sharon
> >
> > Behalf Of Stefan Santesson
> > Sent: Friday, August 27, 2004 6:01 AM
> > To: [email-masked]
> > Subject: RFC 3280 bug? - Special processing for self issued
> certificates
> >
> >
> >
> > I just cam across a small problem that we might want to add to the
> issues
> > list of RFC 3280.
> >
> > At a number of places in the path validation logic define a special 
> > exception case for self issued certificates, expressed with the
> following
> > logic:
> >
> >       If certificate i is self-issued and it is not the final
> >       certificate in the path....
> >
> > When this condition is fulfilled no name constraints applies.
Further,
> > anyPolicy is processed in the certificate even if anyPolicy
> has
> > been inhibited.
> >
> > The latter has the same logic expressed in a slightly different
form:
> >
> >       If the certificate policies extension includes the policy
> >       anyPolicy with the qualifier set AP-Q and either (a)
> >       inhibit_any-policy is greater than 0 or (b) i<n and the
> >       certificate is self-issued, then
> >
> >
> > Now to the problem:
> >
> > If I apply these rules to a self issued certificate that is
perfectly
> > valid inside I path, that certificate may appear as invalid when 
> > examined on
> its
> > own. That is because when it is examined on its own, it is now the
> last
> > certificate in the path and suddenly other rules apply for what is
> valid
> > and
> > what is not.
> >
> > E.g. the self issued certificate may have just anyPolicy present and
> when
> > examined on its own an inhibit_anyPolicy setting of the path will
then
> > result in an empty policy set of the path.
> >
> > The same type of situation may apply to name constraints (at least
in
> > theory)
> >
> > This creates the odd situation where valid self-issued certificates
> can't
> > be
> > examined on their own. Situations where this could be trouble are in 
> > certificate viewers and logic where you manage, examine and handle 
> > individual certificates in a local environment where some valid 
> > certificates can't be validated and thus show up as invalid.
> >
> > Can anyone remember why we can't make all self issued certificates
to
> be
> > exceptions even if they are the last certificate in the path?
> >
> > I can't see the problem here to allow generic processing of all self 
> > issued certificates regardless of position.
> >
> > Maybe I'm missing something.
> >
> > Stefan Santesson

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Sat, 28 Aug 2004 08:27:25 -0400
Importance: Normal
Sender: [email-masked]

Stefan:

I think extensions should be ignored in the trust anchor regardless of their
criticality

For reasons such as MS CAPI, it is best to keep the trust anchors to bear
minimum required.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Saturday, August 28, 2004 5:10 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

If the Path Length constraint is present in the self signed root, it will be
ignored by a X.509 and RFC 3280 compliant path validation implementation.

However, there are implementations that honour Root extensions despite this
and would thus honour Path length constraints present in roots. E.g. I know
that MS CAPI will.

Despite that, I would say that it is wrong to rely on critical extensions in
root certificates since they are ignored in RFC 3280 path validation.

Stefan Santesson

> If CA A is simply another CA, CA B certificate can be validated as an 
> If CA A is trust anchor, I think it can issue CA certificates.  I read 
> both X.509 and 3280 to not enforce constraints in the trust anchor.
> 
> BTW, all this discussion of hierarchies and cross certificates should 
> pathLenConstraint=0, but I was referring to the pathLenConstraint in 
> follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a 
> foreign one) if the
> self-issued certificate of CA A contains pathLenConstraint=0 ?
> 
> However, those cross-certificates will only be trusted if paths are 
> built to them that exclude the certificate that contains the path 
> length constraint.
> 
> CA A issues a cross certificate to CA B with a path length constraint 
> However, users of CA D are able to trust certificates issued by CA C 
> because the cross-certificate from D to B contains no such constraint.
> 
> process paths including all the business controls. As for testing, I'd 
> suggest you have a look at the PKITS test suite which tests all these 
> In case of a "cross-certificate" (so to speak) issued by the same CA 
> for itself, to facilitate the CA key rollover, RFC 3280 seems to to 
> allow the cross-certificate issuance regardless of the 
> cross-certificate is "self-issued" and therefore, in a way, "out of 
> scope" as far as the pathLenConstraint is concerned.
> 
> However, in the case of a "real" cross-certificate, to be issued to 
> another CA with a different name, it is not very clear to me if the
> pathLenConstraint in CA1 affects the possibility of issuing a
> By the way, I wonder how are the most widespread applications handling 
> certificate chains containing cross-certs, in the various cases (e.g. 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei 
> suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto 
> e non possono essere considerate come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> attachments. The statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> e non possono essere considerate come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> attachments. The statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Sat, 28 Aug 2004 10:10:04 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

If the Path Length constraint is present in the self signed root, it will be ignored by a X.509 and RFC 3280 compliant path validation implementation.

However, there are implementations that honour Root extensions despite this and would thus honour Path length constraints present in roots. E.g. I know that MS CAPI will.

Despite that, I would say that it is wrong to rely on critical extensions in root certificates since they are ignored in RFC 3280 path validation.

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> If CA A is simply another CA, CA B certificate can be validated as an end
> (not intermediate certificate).
> 
> If CA A is trust anchor, I think it can issue CA certificates.  I read
> both
> X.509 and 3280 to not enforce constraints in the trust anchor.
> 
> self-issued certificate, I would think the pathLength in that certificate
> should be honored.
> 
> BTW, all this discussion of hierarchies and cross certificates should not
> be
> relevant.  Both X.509 and 3280 are (rightfully) trust model agnostic.
> 
> From: [email-masked] [mailto:[email-masked]]
> On
> pathLenConstraint=0, but I was referring to the pathLenConstraint in the
> trust-point certificate. Virtually all CA public keys are distributed to
> end-users in the form of a self-signed certificate which may (should)
> contain the BasicConstrains extension. Some EU profiles actually mandate
> the
> BasicConstrains to be present and critical.
> 
> Using your example entities, my question can be re-phrased like follows:
> can
> CA A (my trust point) issue a cross-cert to CA B (e.g. a foreign one) if
> the
> self-issued certificate of CA A contains pathLenConstraint=0 ?
> 
> If you are talking about a non-hierarchical trust model, then absolutely
> yes
> any CA can issue any cross-certificates they wish. However, those
> cross-certificates will only be trusted if paths are built to them that
> exclude the certificate that contains the path length constraint.
> 
> CA A issues a cross certificate to CA B with a path length constraint of 0
> CA B issues a cross certificate to CA C
> CA D issues a cross certificate to CA B (no path length constraint)
> 
> Users of CA A have no way to trust certificates issued by CA C (because of
> the path length constraint)
> 
> However, users of CA D are able to trust certificates issued by CA C
> because
> the cross-certificate from D to B contains no such constraint.
> 
> As for your second question, yes there are implementations that process
> paths including all the business controls. As for testing, I'd suggest you
> have a look at the PKITS test suite which tests all these features.
> http://csrc.nist.gov/pki/testing/x509paths.html
> 
> Cheers,
> Sharon
> 
> From: [email-masked] [mailto:[email-masked]]
> On
> In case of a "cross-certificate" (so to speak) issued by the same CA for
> itself, to facilitate the CA key rollover, RFC 3280 seems to to allow the
> cross-certificate issuance regardless of the pathLenConstraint value, on
> the
> ground that in this case the cross-certificate is "self-issued" and
> therefore, in a way, "out of scope" as far as the pathLenConstraint is
> concerned.
> 
> However, in the case of a "real" cross-certificate, to be issued to
> another
> CA with a different name, it is not very clear to me if the
> pathLenConstraint in CA1 affects the possibility of issuing a
> By the way, I wonder how are the most widespread applications handling
> certificate chains containing cross-certs, in the various cases (e.g.
> different values of pethLenConstraint down the chain); has anybody done
> any
> testing to specifically investigate this area?
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi
> allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore
> il
> presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
> comunicazione al riguardo e provvedesse nel contempo alla distruzione del
> messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
> nel presente messaggio nonche' nei suoi eventuali allegati devono essere
> attribuite esclusivamente al mittente e non possono essere considerate
> come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> prohibited
> and could constitute an offence. If you are not the intended addressee
> please advise immediately the sender by using the reply facility in your
> e-mail software and destroy the message and its attachments. The
> statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi
> allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore
> il
> presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
> comunicazione al riguardo e provvedesse nel contempo alla distruzione del
> messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
> nel presente messaggio nonche' nei suoi eventuali allegati devono essere
> attribuite esclusivamente al mittente e non possono essere considerate
> come
> trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
> impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail.
> 
> 
> 
> prohibited
> and could constitute an offence. If you are not the intended addressee
> please advise immediately the sender by using the reply facility in your
> e-mail software and destroy the message and its attachments. The
> statements
> and opinions expressed in this e-mail message are those of the author of
> the
> message and do not necessarily represent those of ACTALIS S.p.A. Besides,
> The contents of this message shall be understood as neither given nor
> endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception or
> amendment, if any, or the consequences thereof.
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 18:52:05 -0400
Importance: Normal
Sender: [email-masked]

If CA A is simply another CA, CA B certificate can be validated as an end
(not intermediate certificate).

If CA A is trust anchor, I think it can issue CA certificates.  I read both
X.509 and 3280 to not enforce constraints in the trust anchor.

To complicate matters further, if the trust anchor issues itself a
self-issued certificate, I would think the pathLength in that certificate
should be honored.

BTW, all this discussion of hierarchies and cross certificates should not be
relevant.  Both X.509 and 3280 are (rightfully) trust model agnostic.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 9:28 AM
To: Sharon Boeyen
Cc: [email-masked]
Subject: R: On cross-certificates and pathLenConstraint

Sharon,

you explained what happens when a cross-certificates contains a
pathLenConstraint=0, but I was referring to the pathLenConstraint in the
trust-point certificate. Virtually all CA public keys are distributed to
end-users in the form of a self-signed certificate which may (should)
contain the BasicConstrains extension. Some EU profiles actually mandate the
BasicConstrains to be present and critical.

Using your example entities, my question can be re-phrased like follows: can
CA A (my trust point) issue a cross-cert to CA B (e.g. a foreign one) if the
self-issued certificate of CA A contains pathLenConstraint=0 ?

Adriano

-----Messaggio originale-----
Da: Sharon Boeyen [mailto:[email-masked]] 
Inviato: venerdì 27 agosto 2004 14.34
A: Santoni Adriano; [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

If you are talking about a non-hierarchical trust model, then absolutely yes
any CA can issue any cross-certificates they wish. However, those
cross-certificates will only be trusted if paths are built to them that
exclude the certificate that contains the path length constraint. 

CA A issues a cross certificate to CA B with a path length constraint of 0
CA B issues a cross certificate to CA C 
CA D issues a cross certificate to CA B (no path length constraint)

Users of CA A have no way to trust certificates issued by CA C (because of
the path length constraint)

However, users of CA D are able to trust certificates issued by CA C because
the cross-certificate from D to B contains no such constraint.  

As for your second question, yes there are implementations that process
paths including all the business controls. As for testing, I'd suggest you
have a look at the PKITS test suite which tests all these features.
http://csrc.nist.gov/pki/testing/x509paths.html

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [email-masked]
Subject: On cross-certificates and pathLenConstraint

Dear list,

can a CA with BasicConstraints.pathLenConstraint=0 issue a cross-certificate
to another CA in a different domain?

In case of a "cross-certificate" (so to speak) issued by the same CA for
itself, to facilitate the CA key rollover, RFC 3280 seems to to allow the
cross-certificate issuance regardless of the pathLenConstraint value, on the
ground that in this case the cross-certificate is "self-issued" and
therefore, in a way, "out of scope" as far as the pathLenConstraint is
concerned.

However, in the case of a "real" cross-certificate, to be issued to another
CA with a different name, it is not very clear to me if the
pathLenConstraint in CA1 affects the possibility of issuing a
cross-certificate to CA2.

By the way, I wonder how are the most widespread applications handling
certificate chains containing cross-certs, in the various cases (e.g.
different values of pethLenConstraint down the chain); has anybody done any
testing to specifically investigate this area?

TIA,
  Adriano

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi
allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore il
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
comunicazione al riguardo e provvedesse nel contempo alla distruzione del
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
nel presente messaggio nonche' nei suoi eventuali allegati devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of ACTALIS S.p.A. Besides,
The contents of this message shall be understood as neither given nor
endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi
allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
comunicazione al riguardo e provvedesse nel contempo alla distruzione del
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
nel presente messaggio nonche' nei suoi eventuali allegati devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of ACTALIS S.p.A. Besides,
The contents of this message shall be understood as neither given nor
endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 17:54:11 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Well,

That doesn't really help. What you say is what I assumed is the case.

However, I don't see any real threats avoided with the current approach,
only problems.

The only aspects that are influenced by this logic are name constraints
and processing anyPolicy when inhibited. I have tried to think hard here
but I can't see any real threats avoided by the current logic.

For all valid paths to a self-issued certificate, the self-issued cert
will be preceded by a valid intermediary CA certificate with a matching
subject name. Lets call that the ICA cert.

It seams reasonable to me that that IF ICA has a valid subject name then
that name would be OK also for the rollover cert, regardless of whether
it is used as an intermediary cert or validated as target cert.

Likewise, if ICA is valid for a certain set of policies, then those
policies would also be good for the rollover cert, regardless of whether
it is used as an intermediary cert or validated as target cert.

I just don't see the threat NOR the real benefit.

The problem that I sense (if this is a problem at all) is that the same
certificate placed under the same certificate path, may be both valid
and invalid at the same time, depending on the context within which you
examine it.

An example:

You look at the certificate path in a viewer and see the complete path
as valid. Then you click on the rollover cert to take a closer look at
it and suddenly that cert shows as invalid. It shows as invalid because
when you take a look just at this cert, it is now at the end of a path
and can't be validated.

Do you see the problem or are my worries completely false here.
I want to know whether I just see ghosts.

Stefan Santesson

> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 27 augusti 2004 17:04
> To: Stefan Santesson; Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> I tried to address that at the end of my email but probably didn't do
a
> very
> good job of it. The reason for making the exceptions was primarily so
that
> CA key rollover didn't interfere with business controls for path
> processing.
> However, if the self-issued certificate is the final certificate in
the
> path
> then it should no longer get excepted because it is now the target of
the
> path validation and therefore the constraints should apply to it. In
the
> intermediate case the certificate's existence is most likely not even
> known
> to the RP. If it is the target cert however, then it is most
definitely
> known to the RP and any business controls, whether imposed directly by
the
> RP through initializing settings for the path validation variables or
by
> CAs
> in cross certs should apply.
> 
> Does that help at all?
> 
> Cheers,
> Sharon
> 
> Sent: Friday, August 27, 2004 10:01 AM
> To: Sharon Boeyen; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> 
> Sharon,
> 
> I think you misread my question/issue.
> 
> I do not question why self-issued certs are excepted from path length
> counting or anyPolicy inhabitation.
> 
> My question is why some exceptions for processing self-issued
certificates
> (mainly regarding processing of anyPolicy and name constraints
checking)
> are
> different if the self-issued certificate is intermediate or the last
> certificate in the path.
> 
> 
> Stefan Santesson
> > From: Sharon Boeyen [mailto:[email-masked]]
> > Sent: den 27 augusti 2004 14:56
> > To: Stefan Santesson; [email-masked]
> > Subject: RE: RFC 3280 bug? - Special processing for self issued
> > certificates
> >
> > Hi Stefan,
> >
> > The reason for the exception cases for self-issued intermediate
> > certificates deals mainly with their role in a CA key rollover
> > situation. In this situation, the fact that a CA has rolled its key,
> > should not change
> the
> > processing of a path. For example if a path length constraint of 3
is
> ok
> > before the rollover that same path length constraint should be ok
with
> the
> > self-issued intermediate cert that perfoms the key rollover. Similar
> logic
> > applies to the anyPolicy and to name constraints. From an X.509
> > perspective, note that the anyPolicy situation was handled by DR
276.
> > FYI, here is
> just
> > the rationale piece of that DR. You can check its processing via the
> > regular docs on Hoyt's server. I could look up the DTC TC numbers if
> > you need them.
> > DR 273 addressed the name constraints issues in this area. Some of
the
> > other
> > areas, such as basic constraints, were addressed in the 4th edition
> text.
> >
> > Rationale text from DR 276:
> > ---------------------
> > One use of self-issued certificates is for a CA to roll over its
> > certificate and/or CRL signing keys without disruption to
> > certification paths that were
> > previously established. In such cases it is convenient for the CA to
> > include
> > the special value anyPolicy in the certificate policies extension of
> the
> > self-issued certificate. This allows the self-issued certificate to
> > provide a link in certification paths for any policy that would be
> > valid if
> the
> > self-issued certificate did not exist. However, there is a problem
if
> the
> > inhibit-any-policy-indicator is set in the certification path
> processing
> > procedure prior to a self-issued certificate. The current text would
> > result in failure of the path because of the existence of anyPolicy
in
> > the self-issued certificate. However, if the self-issued certificate
> > did
> not
> > exist (i.e. the CA had not yet rolled over its key), paths for which
> > specific policies are present in all subsequent certificates may
have
> > passed, but will always fail due to anyPolicy in the self-issued
> > certificate.
> > ---------------------
> > That particular DR was accepted (along with other related ones and
> > original non-defect changes in the 2000 text)
> >
> > These exceptions applied only to intermediate self issued certs
> because
> > the
> > exceptions are to allow paths to have the same result in these areas
> > regardless of whether or not one or more CAs in the path had
undergone
> a
> > key
> > rollover. However, if the end certificate happens to be a
self-issued
> > certificate, the exceptions do not apply because that is the
> certificate
> > that is the one of interest. Therefore if any constraints preclude
> that
> > certificate, it cannot be considered valid.
> >
> > Cheers,
> > Sharon
> >
> > Behalf Of Stefan Santesson
> > Sent: Friday, August 27, 2004 6:01 AM
> > To: [email-masked]
> > Subject: RFC 3280 bug? - Special processing for self issued
> certificates
> >
> >
> >
> > I just cam across a small problem that we might want to add to the
> issues
> > list of RFC 3280.
> >
> > At a number of places in the path validation logic define a special
> > exception case for self issued certificates, expressed with the
> following
> > logic:
> >
> >       If certificate i is self-issued and it is not the final
> >       certificate in the path....
> >
> > When this condition is fulfilled no name constraints applies.
Further,
> > anyPolicy is processed in the certificate even if anyPolicy
> has
> > been inhibited.
> >
> > The latter has the same logic expressed in a slightly different
form:
> >
> >       If the certificate policies extension includes the policy
> >       anyPolicy with the qualifier set AP-Q and either (a)
> >       inhibit_any-policy is greater than 0 or (b) i<n and the
> >       certificate is self-issued, then
> >
> >
> > Now to the problem:
> >
> > If I apply these rules to a self issued certificate that is
perfectly
> > valid inside I path, that certificate may appear as invalid when
> > examined on
> its
> > own. That is because when it is examined on its own, it is now the
> last
> > certificate in the path and suddenly other rules apply for what is
> valid
> > and
> > what is not.
> >
> > E.g. the self issued certificate may have just anyPolicy present and
> when
> > examined on its own an inhibit_anyPolicy setting of the path will
then
> > result in an empty policy set of the path.
> >
> > The same type of situation may apply to name constraints (at least
in
> > theory)
> >
> > This creates the odd situation where valid self-issued certificates
> can't
> > be
> > examined on their own. Situations where this could be trouble are in
> > certificate viewers and logic where you manage, examine and handle
> > individual certificates in a local environment where some valid
> > certificates can't be validated and thus show up as invalid.
> >
> > Can anyone remember why we can't make all self issued certificates
to
> be
> > exceptions even if they are the last certificate in the path?
> >
> > I can't see the problem here to allow generic processing of all self
> > issued certificates regardless of position.
> >
> > Maybe I'm missing something.
> >
> > Stefan Santesson

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Sharon Boeyen <[email-masked]>, [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Fri, 27 Aug 2004 11:04:01 -0400
Sender: [email-masked]

I tried to address that at the end of my email but probably didn't do a very
good job of it. The reason for making the exceptions was primarily so that
CA key rollover didn't interfere with business controls for path processing.
However, if the self-issued certificate is the final certificate in the path
then it should no longer get excepted because it is now the target of the
path validation and therefore the constraints should apply to it. In the
intermediate case the certificate's existence is most likely not even known
to the RP. If it is the target cert however, then it is most definitely
known to the RP and any business controls, whether imposed directly by the
RP through initializing settings for the path validation variables or by CAs
in cross certs should apply. 

Does that help at all?

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, August 27, 2004 10:01 AM
To: Sharon Boeyen; [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates

Sharon,

I think you misread my question/issue.

I do not question why self-issued certs are excepted from path length
counting or anyPolicy inhabitation.

My question is why some exceptions for processing self-issued certificates
(mainly regarding processing of anyPolicy and name constraints checking) are
different if the self-issued certificate is intermediate or the last
certificate in the path.

Stefan Santesson

> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 27 augusti 2004 14:56
> To: Stefan Santesson; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued 
> certificates
> 
> Hi Stefan,
> 
> The reason for the exception cases for self-issued intermediate 
> certificates deals mainly with their role in a CA key rollover 
> situation. In this situation, the fact that a CA has rolled its key, 
> should not change
the
> processing of a path. For example if a path length constraint of 3 is
ok
> before the rollover that same path length constraint should be ok with
the
> self-issued intermediate cert that perfoms the key rollover. Similar
logic
> applies to the anyPolicy and to name constraints. From an X.509 
> perspective, note that the anyPolicy situation was handled by DR 276. 
> FYI, here is
just
> the rationale piece of that DR. You can check its processing via the 
> regular docs on Hoyt's server. I could look up the DTC TC numbers if 
> you need them.
> DR 273 addressed the name constraints issues in this area. Some of the
> other
> areas, such as basic constraints, were addressed in the 4th edition
text.
> 
> Rationale text from DR 276:
> ---------------------
> One use of self-issued certificates is for a CA to roll over its 
> certificate and/or CRL signing keys without disruption to 
> certification paths that were
> previously established. In such cases it is convenient for the CA to
> include
> the special value anyPolicy in the certificate policies extension of
the
> self-issued certificate. This allows the self-issued certificate to 
> provide a link in certification paths for any policy that would be 
> valid if
the
> self-issued certificate did not exist. However, there is a problem if
the
> inhibit-any-policy-indicator is set in the certification path
processing
> procedure prior to a self-issued certificate. The current text would 
> result in failure of the path because of the existence of anyPolicy in 
> the self-issued certificate. However, if the self-issued certificate 
> did
not
> exist (i.e. the CA had not yet rolled over its key), paths for which 
> specific policies are present in all subsequent certificates may have 
> passed, but will always fail due to anyPolicy in the self-issued 
> certificate.
> ---------------------
> That particular DR was accepted (along with other related ones and 
> original non-defect changes in the 2000 text)
> 
> These exceptions applied only to intermediate self issued certs
because
> the
> exceptions are to allow paths to have the same result in these areas 
> regardless of whether or not one or more CAs in the path had undergone
a
> key
> rollover. However, if the end certificate happens to be a self-issued 
> certificate, the exceptions do not apply because that is the
certificate
> that is the one of interest. Therefore if any constraints preclude
that
> certificate, it cannot be considered valid.
> 
> Cheers,
> Sharon
> 
> On
> Behalf Of Stefan Santesson
> Sent: Friday, August 27, 2004 6:01 AM
> To: [email-masked]
> Subject: RFC 3280 bug? - Special processing for self issued
certificates
> 
> 
> 
> I just cam across a small problem that we might want to add to the
issues
> list of RFC 3280.
> 
> At a number of places in the path validation logic define a special 
> exception case for self issued certificates, expressed with the
following
> logic:
> 
>       If certificate i is self-issued and it is not the final
>       certificate in the path....
> 
> When this condition is fulfilled no name constraints applies. Further, 
> anyPolicy is processed in the certificate even if anyPolicy
has
> been inhibited.
> 
> The latter has the same logic expressed in a slightly different form:
> 
>       If the certificate policies extension includes the policy
>       anyPolicy with the qualifier set AP-Q and either (a)
>       inhibit_any-policy is greater than 0 or (b) i<n and the
>       certificate is self-issued, then
> 
> 
> Now to the problem:
> 
> If I apply these rules to a self issued certificate that is perfectly 
> valid inside I path, that certificate may appear as invalid when 
> examined on
its
> own. That is because when it is examined on its own, it is now the
last
> certificate in the path and suddenly other rules apply for what is
valid
> and
> what is not.
> 
> E.g. the self issued certificate may have just anyPolicy present and
when
> examined on its own an inhibit_anyPolicy setting of the path will then 
> result in an empty policy set of the path.
> 
> The same type of situation may apply to name constraints (at least in
> theory)
> 
> This creates the odd situation where valid self-issued certificates
can't
> be
> examined on their own. Situations where this could be trouble are in 
> certificate viewers and logic where you manage, examine and handle 
> individual certificates in a local environment where some valid 
> certificates can't be validated and thus show up as invalid.
> 
> Can anyone remember why we can't make all self issued certificates to
be
> exceptions even if they are the last certificate in the path?
> 
> I can't see the problem here to allow generic processing of all self 
> issued certificates regardless of position.
> 
> Maybe I'm missing something.
> 
> Stefan Santesson

Content-class: urn:content-classes:message
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 15:01:08 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sharon,

I think you misread my question/issue.

I do not question why self-issued certs are excepted from path length
counting or anyPolicy inhabitation.

My question is why some exceptions for processing self-issued
certificates (mainly regarding processing of anyPolicy and name
constraints checking) are different if the self-issued certificate is
intermediate or the last certificate in the path.

Stefan Santesson

> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: den 27 augusti 2004 14:56
> To: Stefan Santesson; [email-masked]
> Subject: RE: RFC 3280 bug? - Special processing for self issued
> certificates
> 
> Hi Stefan,
> 
> The reason for the exception cases for self-issued intermediate
> certificates
> deals mainly with their role in a CA key rollover situation. In this
> situation, the fact that a CA has rolled its key, should not change
the
> processing of a path. For example if a path length constraint of 3 is
ok
> before the rollover that same path length constraint should be ok with
the
> self-issued intermediate cert that perfoms the key rollover. Similar
logic
> applies to the anyPolicy and to name constraints. From an X.509
> perspective,
> note that the anyPolicy situation was handled by DR 276. FYI, here is
just
> the rationale piece of that DR. You can check its processing via the
> regular
> docs on Hoyt's server. I could look up the DTC TC numbers if you need
> them.
> DR 273 addressed the name constraints issues in this area. Some of the
> other
> areas, such as basic constraints, were addressed in the 4th edition
text.
> 
> Rationale text from DR 276:
> ---------------------
> One use of self-issued certificates is for a CA to roll over its
> certificate
> and/or CRL signing keys without disruption to certification paths that
> were
> previously established. In such cases it is convenient for the CA to
> include
> the special value anyPolicy in the certificate policies extension of
the
> self-issued certificate. This allows the self-issued certificate to
> provide
> a link in certification paths for any policy that would be valid if
the
> self-issued certificate did not exist. However, there is a problem if
the
> inhibit-any-policy-indicator is set in the certification path
processing
> procedure prior to a self-issued certificate. The current text would
> result
> in failure of the path because of the existence of anyPolicy in the
> self-issued certificate. However, if the self-issued certificate did
not
> exist (i.e. the CA had not yet rolled over its key), paths for which
> specific policies are present in all subsequent certificates may have
> passed, but will always fail due to anyPolicy in the self-issued
> certificate.
> ---------------------
> That particular DR was accepted (along with other related ones and
> original
> non-defect changes in the 2000 text)
> 
> These exceptions applied only to intermediate self issued certs
because
> the
> exceptions are to allow paths to have the same result in these areas
> regardless of whether or not one or more CAs in the path had undergone
a
> key
> rollover. However, if the end certificate happens to be a self-issued
> certificate, the exceptions do not apply because that is the
certificate
> that is the one of interest. Therefore if any constraints preclude
that
> certificate, it cannot be considered valid.
> 
> Cheers,
> Sharon
> 
> On
> Behalf Of Stefan Santesson
> Sent: Friday, August 27, 2004 6:01 AM
> To: [email-masked]
> Subject: RFC 3280 bug? - Special processing for self issued
certificates
> 
> 
> 
> I just cam across a small problem that we might want to add to the
issues
> list of RFC 3280.
> 
> At a number of places in the path validation logic define a special
> exception case for self issued certificates, expressed with the
following
> logic:
> 
>       If certificate i is self-issued and it is not the final
>       certificate in the path....
> 
> When this condition is fulfilled no name constraints applies.
> Further, anyPolicy is processed in the certificate even if anyPolicy
has
> been inhibited.
> 
> The latter has the same logic expressed in a slightly different form:
> 
>       If the certificate policies extension includes the policy
>       anyPolicy with the qualifier set AP-Q and either (a)
>       inhibit_any-policy is greater than 0 or (b) i<n and the
>       certificate is self-issued, then
> 
> 
> Now to the problem:
> 
> If I apply these rules to a self issued certificate that is perfectly
> valid
> inside I path, that certificate may appear as invalid when examined on
its
> own. That is because when it is examined on its own, it is now the
last
> certificate in the path and suddenly other rules apply for what is
valid
> and
> what is not.
> 
> E.g. the self issued certificate may have just anyPolicy present and
when
> examined on its own an inhibit_anyPolicy setting of the path will then
> result in an empty policy set of the path.
> 
> The same type of situation may apply to name constraints (at least in
> theory)
> 
> This creates the odd situation where valid self-issued certificates
can't
> be
> examined on their own. Situations where this could be trouble are in
> certificate viewers and logic where you manage, examine and handle
> individual certificates in a local environment where some valid
> certificates
> can't be validated and thus show up as invalid.
> 
> Can anyone remember why we can't make all self issued certificates to
be
> exceptions even if they are the last certificate in the path?
> 
> I can't see the problem here to allow generic processing of all self
> issued
> certificates regardless of position.
> 
> Maybe I'm missing something.
> 
> Stefan Santesson

Content-Class: urn:content-classes:message
Subject: R: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 15:27:37 +0200
Importance: normal
From: "Santoni Adriano" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sharon,

you explained what happens when a cross-certificates contains a pathLenConstraint=0, but I was referring to the pathLenConstraint in the trust-point certificate. Virtually all CA public keys are distributed to end-users in the form of a self-signed certificate which may (should) contain the BasicConstrains extension. Some EU profiles actually mandate the BasicConstrains to be present and critical.

Using your example entities, my question can be re-phrased like follows: can CA A (my trust point) issue a cross-cert to CA B (e.g. a foreign one) if the self-issued certificate of CA A contains pathLenConstraint=0 ?

>From another viewpoint: setting pathLenConstraint=0 to prevent hierarchical SubCAs does also hinder cross-certificates?

Adriano

-----Messaggio originale-----
Da: Sharon Boeyen [mailto:[email-masked]] 
Inviato: venerdì 27 agosto 2004 14.34
A: Santoni Adriano; [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

If you are talking about a non-hierarchical trust model, then absolutely yes any CA can issue any cross-certificates they wish. However, those cross-certificates will only be trusted if paths are built to them that exclude the certificate that contains the path length constraint. 

CA A issues a cross certificate to CA B with a path length constraint of 0 CA B issues a cross certificate to CA C 
CA D issues a cross certificate to CA B (no path length constraint)

Users of CA A have no way to trust certificates issued by CA C (because of the path length constraint)

However, users of CA D are able to trust certificates issued by CA C because the cross-certificate from D to B contains no such constraint.  

As for your second question, yes there are implementations that process paths including all the business controls. As for testing, I'd suggest you have a look at the PKITS test suite which tests all these features. http://csrc.nist.gov/pki/testing/x509paths.html

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [email-masked]
Subject: On cross-certificates and pathLenConstraint

Dear list,

can a CA with BasicConstraints.pathLenConstraint=0 issue a cross-certificate to another CA in a different domain?

In case of a "cross-certificate" (so to speak) issued by the same CA for itself, to facilitate the CA key rollover, RFC 3280 seems to to allow the cross-certificate issuance regardless of the pathLenConstraint value, on the ground that in this case the cross-certificate is "self-issued" and therefore, in a way, "out of scope" as far as the pathLenConstraint is concerned.

However, in the case of a "real" cross-certificate, to be issued to another CA with a different name, it is not very clear to me if the pathLenConstraint in CA1 affects the possibility of issuing a cross-certificate to CA2.

By the way, I wonder how are the most widespread applications handling certificate chains containing cross-certs, in the various cases (e.g. different values of pethLenConstraint down the chain); has anybody done any testing to specifically investigate this area?

TIA,
  Adriano

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Date: Fri, 27 Aug 2004 14:15:46 +0100
From: Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: Yet another nitty RFC 3280 bug
Sender: [email-masked]

Stefan Santesson wrote:
> When we are into filing small bugs, here is another one (unless already
> noted):
> 
> Page 77:
>   (h) If the issuer and subject names are not identical
> 
> I believe that this line means to say:
>   (h) If the certificate is not self-issued
> 
> The term self-issued is defined with a slightly different definition,
> adding the aspect that the names must not be empty.
> 
> Section 6:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
> 
> 

On the subject of "identical" should its use above be interpreted as
identical encodings of DNs or simply "matching" that is following the
name comparison rules mentioned in 4.1.2.4?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Subject: RE: RFC 3280 bug? - Special processing for self issued certificat es
Date: Fri, 27 Aug 2004 08:56:21 -0400
Sender: [email-masked]

Hi Stefan,

The reason for the exception cases for self-issued intermediate certificates
deals mainly with their role in a CA key rollover situation. In this
situation, the fact that a CA has rolled its key, should not change the
processing of a path. For example if a path length constraint of 3 is ok
before the rollover that same path length constraint should be ok with the
self-issued intermediate cert that perfoms the key rollover. Similar logic
applies to the anyPolicy and to name constraints. From an X.509 perspective,
note that the anyPolicy situation was handled by DR 276. FYI, here is just
the rationale piece of that DR. You can check its processing via the regular
docs on Hoyt's server. I could look up the DTC TC numbers if you need them.
DR 273 addressed the name constraints issues in this area. Some of the other
areas, such as basic constraints, were addressed in the 4th edition text.

Rationale text from DR 276:
---------------------
One use of self-issued certificates is for a CA to roll over its certificate
and/or CRL signing keys without disruption to certification paths that were
previously established. In such cases it is convenient for the CA to include
the special value anyPolicy in the certificate policies extension of the
self-issued certificate. This allows the self-issued certificate to provide
a link in certification paths for any policy that would be valid if the
self-issued certificate did not exist. However, there is a problem if the
inhibit-any-policy-indicator is set in the certification path processing
procedure prior to a self-issued certificate. The current text would result
in failure of the path because of the existence of anyPolicy in the
self-issued certificate. However, if the self-issued certificate did not
exist (i.e. the CA had not yet rolled over its key), paths for which
specific policies are present in all subsequent certificates may have
passed, but will always fail due to anyPolicy in the self-issued
certificate.
--------------------- 
That particular DR was accepted (along with other related ones and original
non-defect changes in the 2000 text)

These exceptions applied only to intermediate self issued certs because the
exceptions are to allow paths to have the same result in these areas
regardless of whether or not one or more CAs in the path had undergone a key
rollover. However, if the end certificate happens to be a self-issued
certificate, the exceptions do not apply because that is the certificate
that is the one of interest. Therefore if any constraints preclude that
certificate, it cannot be considered valid. 

Cheers,
Sharon  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Friday, August 27, 2004 6:01 AM
To: [email-masked]
Subject: RFC 3280 bug? - Special processing for self issued certificates

I just cam across a small problem that we might want to add to the issues
list of RFC 3280.

At a number of places in the path validation logic define a special
exception case for self issued certificates, expressed with the following
logic:

      If certificate i is self-issued and it is not the final
      certificate in the path....

When this condition is fulfilled no name constraints applies. 
Further, anyPolicy is processed in the certificate even if anyPolicy has
been inhibited.

The latter has the same logic expressed in a slightly different form:

      If the certificate policies extension includes the policy
      anyPolicy with the qualifier set AP-Q and either (a)
      inhibit_any-policy is greater than 0 or (b) i<n and the
      certificate is self-issued, then

Now to the problem:

If I apply these rules to a self issued certificate that is perfectly valid
inside I path, that certificate may appear as invalid when examined on its
own. That is because when it is examined on its own, it is now the last
certificate in the path and suddenly other rules apply for what is valid and
what is not.

E.g. the self issued certificate may have just anyPolicy present and when
examined on its own an inhibit_anyPolicy setting of the path will then
result in an empty policy set of the path.

The same type of situation may apply to name constraints (at least in
theory)

This creates the odd situation where valid self-issued certificates can't be
examined on their own. Situations where this could be trouble are in
certificate viewers and logic where you manage, examine and handle
individual certificates in a local environment where some valid certificates
can't be validated and thus show up as invalid.

Can anyone remember why we can't make all self issued certificates to be
exceptions even if they are the last certificate in the path?

I can't see the problem here to allow generic processing of all self issued
certificates regardless of position.

Maybe I'm missing something.

Stefan Santesson

From: Sharon Boeyen <[email-masked]>
To: "'Santoni Adriano'" <[email-masked]>, [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 08:33:49 -0400
Sender: [email-masked]

If you are talking about a non-hierarchical trust model, then absolutely yes
any CA can issue any cross-certificates they wish. However, those
cross-certificates will only be trusted if paths are built to them that
exclude the certificate that contains the path length constraint. 

CA A issues a cross certificate to CA B with a path length constraint of 0
CA B issues a cross certificate to CA C 
CA D issues a cross certificate to CA B (no path length constraint)

Users of CA A have no way to trust certificates issued by CA C (because of
the path length constraint)

However, users of CA D are able to trust certificates issued by CA C because
the cross-certificate from D to B contains no such constraint.  

As for your second question, yes there are implementations that process
paths including all the business controls. As for testing, I'd suggest you
have a look at the PKITS test suite which tests all these features.
http://csrc.nist.gov/pki/testing/x509paths.html

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Friday, August 27, 2004 5:37 AM
To: [email-masked]
Subject: On cross-certificates and pathLenConstraint

Dear list,

can a CA with BasicConstraints.pathLenConstraint=0 issue a cross-certificate
to another CA in a different domain?

In case of a "cross-certificate" (so to speak) issued by the same CA for
itself, to facilitate the CA key rollover, RFC 3280 seems to to allow the
cross-certificate issuance regardless of the pathLenConstraint value, on the
ground that in this case the cross-certificate is "self-issued" and
therefore, in a way, "out of scope" as far as the pathLenConstraint is
concerned.

However, in the case of a "real" cross-certificate, to be issued to another
CA with a different name, it is not very clear to me if the
pathLenConstraint in CA1 affects the possibility of issuing a
cross-certificate to CA2.

By the way, I wonder how are the most widespread applications handling
certificate chains containing cross-certs, in the various cases (e.g.
different values of pethLenConstraint down the chain); has anybody done any
testing to specifically investigate this area?

TIA,
  Adriano

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi
allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore il
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una
comunicazione al riguardo e provvedesse nel contempo alla distruzione del
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute
nel presente messaggio nonche' nei suoi eventuali allegati devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non
impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of ACTALIS S.p.A. Besides,
The contents of this message shall be understood as neither given nor
endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.

Content-class: urn:content-classes:message
Subject: Yet another nitty RFC 3280 bug
Date: Fri, 27 Aug 2004 13:00:30 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

When we are into filing small bugs, here is another one (unless already
noted):

Page 77:
  (h) If the issuer and subject names are not identical

I believe that this line means to say:
  (h) If the certificate is not self-issued

The term self-issued is defined with a slightly different definition,
adding the aspect that the names must not be empty.

Section 6:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty.

Stefan Santesson

Content-class: urn:content-classes:message
Subject: RE: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 12:42:12 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santoni Adriano" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

No,

A CA, when represented by a CA certificate with pathLengthConstraints =
0, can't issue a valid cross cert to another CA.

To be really accurate: The cross cert would actually be valid as the
last cert in a path but nothing under that cross cert would be valid.

Stefan Santesson

> Sent: den 27 augusti 2004 11:37
> To: [email-masked]
> can a CA with BasicConstraints.pathLenConstraint=0 issue a
> cross-certificate to another CA in a different domain?
> 
> In case of a "cross-certificate" (so to speak) issued by the same CA
for
> itself, to facilitate the CA key rollover, RFC 3280 seems to to allow
> the cross-certificate issuance regardless of the pathLenConstraint
> value, on the ground that in this case the cross-certificate is
> "self-issued" and therefore, in a way, "out of scope" as far as the
> pathLenConstraint is concerned.
> 
> However, in the case of a "real" cross-certificate, to be issued to
> another CA with a different name, it is not very clear to me if the
> pathLenConstraint in CA1 affects the possibility of issuing a
> By the way, I wonder how are the most widespread applications handling
> certificate chains containing cross-certs, in the various cases (e.g.
done
> any testing to specifically investigate this area?
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei
suoi
> allegati e vietato e potrebbe costituire reato. Se ha ricevuto per
errore
> il presente messaggio, Le saremmo grati se ci inviasse, via e-mail,
una
> comunicazione al riguardo e provvedesse nel contempo alla distruzione
del
> messaggio stesso e dei suoi eventuali allegati.
> Le dichiarazioni contenute nel presente messaggio nonche' nei suoi
e
> non possono essere considerate come trasmesse o autorizzate da ACTALIS
> S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei
> confronti del destinatario o di terzi.
> intercettazioni, modifiche o danneggiamenti del presente messaggio
e-mail.
> prohibited and could constitute an offence. If you are not the
intended
> addressee please advise immediately the sender by using the reply
facility
> in your e-mail software and destroy the message and its attachments.
The
> statements and opinions expressed in this e-mail message are those of
the
> author of the message and do not necessarily represent those of
ACTALIS
> S.p.A. Besides, The contents of this message shall be understood as
> neither given nor endorsed by ACTALIS S.p.A..
> ACTALIS S.p.A. does not accept liability for corruption, interception
or
> amendment, if any, or the consequences thereof.
> 
> 

Content-class: urn:content-classes:message
Subject: RFC 3280 bug? - Special processing for self issued certificates
Date: Fri, 27 Aug 2004 11:01:09 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I just cam across a small problem that we might want to add to the
issues list of RFC 3280.

At a number of places in the path validation logic define a special
exception case for self issued certificates, expressed with the
following logic:

      If certificate i is self-issued and it is not the final
      certificate in the path....

When this condition is fulfilled no name constraints applies. 
Further, anyPolicy is processed in the certificate even if anyPolicy has
been inhibited.

The latter has the same logic expressed in a slightly different form:

      If the certificate policies extension includes the policy
      anyPolicy with the qualifier set AP-Q and either (a)
      inhibit_any-policy is greater than 0 or (b) i<n and the
      certificate is self-issued, then

Now to the problem:

If I apply these rules to a self issued certificate that is perfectly
valid inside I path, that certificate may appear as invalid when
examined on its own. That is because when it is examined on its own, it
is now the last certificate in the path and suddenly other rules apply
for what is valid and what is not.

E.g. the self issued certificate may have just anyPolicy present and
when examined on its own an inhibit_anyPolicy setting of the path will
then result in an empty policy set of the path.

The same type of situation may apply to name constraints (at least in
theory)

This creates the odd situation where valid self-issued certificates
can't be examined on their own. Situations where this could be trouble
are in certificate viewers and logic where you manage, examine and
handle individual certificates in a local environment where some valid
certificates can't be validated and thus show up as invalid.

Can anyone remember why we can't make all self issued certificates to be
exceptions even if they are the last certificate in the path?

I can't see the problem here to allow generic processing of all self
issued certificates regardless of position.

Maybe I'm missing something.

Stefan Santesson

Content-Class: urn:content-classes:message
Subject: On cross-certificates and pathLenConstraint
Date: Fri, 27 Aug 2004 11:37:13 +0200
Importance: normal
From: "Santoni Adriano" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Dear list,

can a CA with BasicConstraints.pathLenConstraint=0 issue a
cross-certificate to another CA in a different domain?

In case of a "cross-certificate" (so to speak) issued by the same CA for
itself, to facilitate the CA key rollover, RFC 3280 seems to to allow
the cross-certificate issuance regardless of the pathLenConstraint
value, on the ground that in this case the cross-certificate is
"self-issued" and therefore, in a way, "out of scope" as far as the
pathLenConstraint is concerned.

However, in the case of a "real" cross-certificate, to be issued to
another CA with a different name, it is not very clear to me if the
pathLenConstraint in CA1 affects the possibility of issuing a
cross-certificate to CA2.

By the way, I wonder how are the most widespread applications handling
certificate chains containing cross-certs, in the various cases (e.g.
different values of pethLenConstraint down the chain); has anybody done
any testing to specifically investigate this area?

TIA,
  Adriano

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure Operational  Protocols: Certificate Store Access via HTTP' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Wed, 25 Aug 2004 15:01:55 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Internet X.509 Public Key Infrastructure Operational Protocols: Certificate 
   Store Access via HTTP '
   <draft-ietf-pkix-certstore-http-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-09-08.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-08.txt

Date: Wed, 25 Aug 2004 12:39:00 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: boolean defaults
Cc: [email-masked]
Sender: [email-masked]

It had been proposed to change the three boolean values
to OPTIONAL.

     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE, 
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE, 
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE, 

I am not sure whether this is useful or necessary.

It seems to me that it is sufficient just to *OR* the
two occurences in a query and the server conf in order
to get the most restrictive setting. 

Date: Wed, 25 Aug 2004 12:38:27 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: SCVP trust anchors.
Cc: [email-masked]
Sender: [email-masked]

The current text concerning trust anchors is: 

..

3.2.14 trustAnchors 
   
  The OPTIONAL trustAnchors item specifies the trust anchors to be 
  used by the SCVP server.  One or more certificate policy MAY be 
  associated with each trust anchor.  If a trustAnchors item is 
  present, the server MUST NOT use any certification path trust 
  anchors other than those provided. 

..

6.5 trustAnchors 
   
  The trustAnchors item specifies the default trust anchors that the 
  SCVP server will use if the client directly or indirectly omits the 
  trustAnchours from the request.   

I am not sure whether this text is clear enough to allow the 
following:

1 - the server has a list of trust anchors, and the client may select
    a subset. (an enterprise server)

2 - The server has a potentially empty default list of trust anchors, 
    and the client can (must if empty) select another one.

In fact, I'd rather split the second one into two different policies,
or in other words, when the default server list is empty, the client's
list is taken as is, otherwise only the elemnts in both client and
server list are taken. 

Date: Wed, 25 Aug 2004 12:08:21 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: scvp
Cc: [email-masked]
Sender: [email-masked]

The following message was not send to the list a few days ago.

The path validation algorithm is defined for end certificates. 

> [TF] If the path validation algorithm in 3280 cannot validate CA
> certificates I would consider that a defect against 3280. However I
> cannot see ant such defect so if you believe that to be the case you
> need to take that up with the authors.

The text explicitely says that the algorithm is for end entity certs: 

6.1.3 at the end: 

   If i is not equal to n, continue by performing the preparatory steps
   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
   listed in 6.1.5.

6.1.5  Wrap-up procedure

   To complete the processing of the end entity certificate ...

Take a invalid path  trust ... CA1 --> CA2 
with CA1 having a pathlength constraint 0 in its cert.

path length is n. CA1 is trusted somehow. 
maxpathlength = n
when you arrice at CA1, the maxpathlength will be 2 
path length constraint is 0 ==> set maxpathlength = 0

Then at the last step the 6.1.5 procedure is called
which does not fail. 

Please tell for your scenario who is responsible to detect
the wrong path. 

> [TF] Before we get into the solution, can you provide some examples
> (like I did for isCA) where path length is a useful policy input. In the
> example I cited, use of the isCA Boolean does not require path length as
> a policy input.

Just apply recursion up to the trust anchor. 

> * 
> * We could require that
> * 
> *    when isCA is set,
> *    the DPV client MUST provide the path to the trust anchor,
> *    or MUST provide the chain from the ee to the ca cert to be
> validated,
> *    including the ee cert,
> * 
> * (
> *    or in case of multiple paths that validate a CA, the state of the
> path
> * validation
> *    algorithm for any of the paths MUST be identical. ???
> * )

The previous was a proposition intened to be commnted. 

> * 
> * > We do have a facility to do this via the basic constraints extension
> * > in a CA cert, but we know that this feature is hard to use unless
> one
> * > knows the structure of the PKI pointed to by a cross cert that
> * > incorporates this feature. As a result, I generally suggest not
> * > making use of this optional part of this extension. I've heard
> others
> * > make the same comment, e.g., Sharon Boyen. I realize that 3280 makes
> * > no comment about this feature, so we have not deprecated it, but ...
> * 
> * I think it is not a bad practice to have pathlength = 0 in CA certs
> * that are only used to sign EE certs.
> [TF] That is the only useful instance of path length for a
> infrastructure management perspective but not for a validation
> perspective.

What do you mean by this? 

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP issue
Date: Tue, 24 Aug 2004 12:27:37 -0700
Importance: Normal
Sender: [email-masked]

Steve,

I agree with your proposal for MUST support OIDs, SHOULD/MAY support
parameters.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Stephen Kent
Sent: Friday, August 13, 2004 8:01 AM
To: [email-masked]
Subject: SCVP issue

Folks,

A few of us have been discussing (off list) the issue of having a
client send an OID to specify a validation policy at an SCVP (DPV)
server, vs. having the client send parameters to direct validation.

My position is that support for OID-based policy references should be
the default, and the mandatory minimum policy specification mechanism
for both clients and servers, i.e., a MUST, and that support for
explicit parameter passing should be an option, a SHOULD or MAY.
there are several reasons for
my saying this.

First, configuring a client to pass an OID is obviously simpler than
configuring the client with all the parameters needed to direct path
validation, and with the default policy feature that SCVP must
support, one could image a zero-config  situation in some contexts.
In general enterprises find it hard to manage configuration info for
every client, and this problem is only magnified as the number of
configuration parameters grows. Thus OID-specified validation is much
simpler than parameter-specified validation, from a client
perspective. Since the "S" in SCVP does stand for simple, ...

Also, as Trevor brought to my attention, one may choose to define
additional
parameters that define cert validity for a given application context,
beyond the standard set of parameters used for path validation. If we
want a allow an administrator to define such validation policies, we
can't assume that standard clients will be prepared to convey the
necessary parameters. This is especially
true if we assume that the clients and servers are not produced by
the same vendor. So, only via use of OIDs can we hope to allow such
customization of cert validity in mixed vendor (or mixed version)
environments.

These two points seem to argue for making OIDs the MUST method for
conveying cert validation selection between  client and server,
relegating parameter passing to a lesser status, e.g., SHOULD or MAY.

I'd like to receive feedback fro the list on this issue.

Steve

Date: Tue, 24 Aug 2004 13:20:37 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: SCVP issue
Sender: [email-masked]

I agree with the "simple" protocol argument and I like the OIDs as the 
mandatory over the parameters.  As to whether oid and parameters are in 
the same structure or in a separate extension ... well that's the next 
discussion.

spt

Stephen Kent wrote:

>
> Folks,
>
> A few of us have been discussing (off list) the issue of having a 
> client send an OID to specify a validation policy at an SCVP (DPV) 
> server, vs. having the client send parameters to direct validation.
>
> My position is that support for OID-based policy references should be 
> the default, and the mandatory minimum policy specification mechanism 
> for both clients and servers, i.e., a MUST, and that support for 
> explicit parameter passing should be an option, a SHOULD or MAY. there 
> are several reasons for
> my saying this.
>
> First, configuring a client to pass an OID is obviously simpler than 
> configuring the client with all the parameters needed to direct path 
> validation, and with the default policy feature that SCVP must 
> support, one could image a zero-config  situation in some contexts. In 
> general enterprises find it hard to manage configuration info for 
> every client, and this problem is only magnified as the number of 
> configuration parameters grows. Thus OID-specified validation is much 
> simpler than parameter-specified validation, from a client 
> perspective. Since the "S" in SCVP does stand for simple, ...
>
> Also, as Trevor brought to my attention, one may choose to define 
> additional
> parameters that define cert validity for a given application context, 
> beyond the standard set of parameters used for path validation. If we 
> want a allow an administrator to define such validation policies, we 
> can't assume that standard clients will be prepared to convey the 
> necessary parameters. This is especially
> true if we assume that the clients and servers are not produced by the 
> same vendor. So, only via use of OIDs can we hope to allow such 
> customization of cert validity in mixed vendor (or mixed version) 
> environments.
>
> These two points seem to argue for making OIDs the MUST method for 
> conveying cert validation selection between  client and server, 
> relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>
> I'd like to receive feedback fro the list on this issue.
>
> Steve
>

Content-class: urn:content-classes:message
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 24 Aug 2004 09:19:57 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 24, 2004 4:38 AM
* To: [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* Hi All,
* 
* I have two more things to concern for SCVP draft 15 as below:
* 
* 1- According to SCVP draft 15, 'RequestReference' is not OPTIONAL in
scvp
* response structure.As by default 'requestRefHash' is TRUE in Query, if
* server fails to calculate hash for any reason how can the server sends
* 'Internal Error' response back to client without 'RequestReference'
when
* it
* is set as mandatory ? Should 'RequestReference' not be OPTIONAL?
[TF] this is already fixed in 16
* 
* 2- Section 6.2 describes PolicyID which seems to belong only to
default
* validation policy. If so, it should be an optional element in scvp
* response
* because if client uses validation policy other than default, there is
no
* need to insert PolicyID in scvp response.
[TF] If the client uses a validation policy other that default which
does not define every parameter, and the client also omits the missing
values in the request, the default values are used for whatever is
missing therefore the policy ID potentially applies to any response. 
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: <[email-masked]>
* To: <[email-masked]>
* Sent: Thursday, August 05, 2004 05:06
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* >
* >
* >
* > Folks,
* >
* > It is time to get serious and finish up SCVP.  In the slides
presented
* at
* our
* > meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* > of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* > do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* >
* > I am requesting that everyone in the WG make time to review SCVP and
* document
* > any issues you find by Friday the 13th.  (I am not setting a
deadline
* for
* > terminating discussion - it may take a few days to reach consensus
on
* the
* > issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* > list is stable, I am sure we can work out solutions.
* >
* > Please post all technical comments to the list.  Editorial comments
can
* be
* > sent to Trevor directly.  Include SCVP in the subject line
regardless!
* >
* > Thanks,
* >
* > Tim Polk
* >

To: "Trevor Freeman" <[email-masked]>
Cc: [email-masked], "Peter Sylvester" <[email-masked]>
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
From: Tom Gindin <[email-masked]>
Date: Tue, 24 Aug 2004 07:41:48 -0400
Sender: [email-masked]

        Trevor:

        Path length 0 reflects a real condition - it can be imposed as a 
way of enforcing one of the following statements: "the subject is a 
departmental CA and may issue EE certificates but no others" or "I trust 
you to issue EE certificates, but I do not choose to trust your 
cross-certificates".  Of course, the first statement occurs only in a 
hierarchical relationship and the second does not - indeed the second 
statement is one an RP might want to make about a trust anchor if he 
could.  OTOH I have no idea how an issuer would sensibly decide that one 
subject CA gets a path length of 3 while another subject CA gets a path 
length of 4 - AFAIK we're just following X.509 there.
        I guess it would be helpful to break this feature out into two 
questions to everybody who's administered a CA lately (or supported those 
who do):
        First, have you issued a cross certificate (or tried to, or asked 
if the CA software supports it) with path length between 1 and 10?  I'm 
assuming that path lengths greater than 10 are used as loop limits rather 
than actual security constraints.
        Second, have you issued a cross certificate (or tried to, or asked 
if the CA software supports it) with path length 0?

                Tom Gindin

P.S.-   The opinions expressed above are mine personally, and not 
necessarily those of my employer.

"Trevor Freeman" <[email-masked]>
Sent by: [email-masked]
08/18/2004 04:24 PM
 
        To:     "Peter Sylvester" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: PKIX WG Agenda for 60th IETF (second try!)

Hi Peter,
I don't know if this is broken or not. I am applying a is "this a real
or useful problem to solve filer check" before I proceed to problem
analysis or solution. I have never found the path length as a valuable
input into an validation criteria. However if there is consensus to
solve this in the context of SCVP then I will spend some time on it.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 18, 2004 3:36 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > I cannot begin to understand why anyone would set an arbitrary
length of
* > a path i.e. is good as long as there are only 3 CA certificates in
the
* > path, however since you raised the point in conjunction to DPD
requests,
* > then the simplest solution is to allow the client to request all
paths.
* 
* you are insisting that I mentioned a use case for DPD,
* but my the question is for DPV as I said already.
* In fact, DPD does not have a problem here, since you can implement
* several paths, as you say (using the servercontext parameter).
* (We havn't even started to handle policies).
* 
* I don't think that servercontext is intended for DPV.
* 
* BTW: The example seems wrong to me, none of the paths is valid.
* The CA3 certs are one too low.
* 
*  EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
*                   <- CA3withpathlength2 <- CAY ..
* 
* It seem that you finally admit that there is a problem, and now
* you escape to a social argument. if someone thinks that the situation
* is technical non sense, please tell.
* IMO the PKI structure is conformant with the standards.
* 
* One may choose a solution to provide the path EE <- CA1 <- CA2
* in some way, and ask for a valid path.
* 
* or, one may restruct SCVP DPV processing for certain use cases
* in order to ensure that the server can respond to a client.
* 
* Peter
* 
* PS: you haven't yet answered to two other remarks.
* 
* 
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[email-masked]]
* > * Sent: Sunday, August 15, 2004 4:52 AM
* > * To: [email-masked]; Trevor Freeman
* > * Cc: [email-masked]
* > * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* > *
* > * > Hi Peter,
* > * > The validation algorithm in 3280 section 6 works for all
* > certificates.
* > *
* > * The algorithm is defined for EE-certs.
* > *
* > * > Trevor
* > * >
* > *
* > *
* > * You have not commented the following:
* > *
* > * > *
* > * > * Assume you want a valid path for CA2 signing CA1 and an EE
cert
* > * > * and you have a situation like
* > * > *
* > * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX ..
sometrustanchor
* > * > *                    <- CA3withpathlength1 <- CAY ..
* > othetrustanchor.
* > * > *
* > * > * you cannot avoid that the SCVP server returns the first path
* > * > * which would not be valid to sign EE with an intermediate CA1.
* > * > *
* > *
* > *
* >
* >

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace...
Date: Tue, 24 Aug 2004 16:37:52 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Hi All,

I have two more things to concern for SCVP draft 15 as below:

1- According to SCVP draft 15, 'RequestReference' is not OPTIONAL in scvp
response structure.As by default 'requestRefHash' is TRUE in Query, if
server fails to calculate hash for any reason how can the server sends
'Internal Error' response back to client without 'RequestReference' when it
is set as mandatory ? Should 'RequestReference' not be OPTIONAL?

2- Section 6.2 describes PolicyID which seems to belong only to default
validation policy. If so, it should be an optional element in scvp response
because if client uses validation policy other than default, there is no
need to insert PolicyID in scvp response.

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-08.txt
Date: Mon, 23 Aug 2004 15:22:03 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Operational 
			  Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-08.txt
	Pages		: 0
	Date		: 2004-8-23
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certstore-http-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-certstore-http-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-certstore-http-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 23 Aug 2004 11:51:39 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SCVP issue
Cc: russ housley <[email-masked]>, [email-masked]
Sender: [email-masked]

Denis,

I'd glad to hear the lead author of 3379 say that you believe that we 
don't need validation algorithm as a separate part of the validation 
specification.  I had come to believe that too.

Trevor,  I second Denis's suggestion to remove  validationAlg form SCVP.

Russ, as the other author of 3379, do you have an objection?

Steve

Date: Mon, 23 Aug 2004 13:24:06 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: Wen-Cheng Wang <[email-masked]>, [email-masked]
Subject: Re: SCVP issue
Sender: [email-masked]

Trevor,

> My position is that since SCVP is supposed to be a "simple"
> protocol, it sould in default provide better support to simple clients.

> I do not object to provide the possibility to allow a "complex"
> client to send a full set of parameters to a "complex"
> server. However, this can be done via an EXTENSION
> mechanism. I strongly suggest that we should remove
> all parameter fields from the current syntax and instead add
> an EXTENSION mechanism to the SCVP Query
> structure or the Validation Policy reference structure.

> And then, we can define some standard EXTENSIONs
> to allow a "complex" client to send RFC 3280 parameters,
> revocation info requirements, or additional conditions (such
> as name matching rules, key usage requirements, etc.)
> to a  "complex" server that understand these extensions.

> This way, we will keep the basic syntax of SCVP as simple
> as possible but preserve the extensibility of the protocol.

I fully support this position.

Denis

> =====
> Wen-Cheng Wang
> 
> 
> ----- Original Message ----- 
> From: "Stephen Kent" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, August 13, 2004 11:01 PM
> Subject: SCVP issue
> 
> 
> 
>>Folks,
>>
>>A few of us have been discussing (off list) the issue of having a
>>client send an OID to specify a validation policy at an SCVP (DPV)
>>server, vs. having the client send parameters to direct validation.
>>
>>My position is that support for OID-based policy references should be
>>the default, and the mandatory minimum policy specification mechanism
>>for both clients and servers, i.e., a MUST, and that support for
>>explicit parameter passing should be an option, a SHOULD or MAY.
>>there are several reasons for
>>my saying this.
>>
>>First, configuring a client to pass an OID is obviously simpler than
>>configuring the client with all the parameters needed to direct path
>>validation, and with the default policy feature that SCVP must
>>support, one could image a zero-config  situation in some contexts.
>>In general enterprises find it hard to manage configuration info for
>>every client, and this problem is only magnified as the number of
>>configuration parameters grows. Thus OID-specified validation is much
>>simpler than parameter-specified validation, from a client
>>perspective. Since the "S" in SCVP does stand for simple, ...
>>
>>Also, as Trevor brought to my attention, one may choose to define
> 
> additional
> 
>>parameters that define cert validity for a given application context,
>>beyond the standard set of parameters used for path validation. If we
>>want a allow an administrator to define such validation policies, we
>>can't assume that standard clients will be prepared to convey the
>>necessary parameters. This is especially
>>true if we assume that the clients and servers are not produced by
>>the same vendor. So, only via use of OIDs can we hope to allow such
>>customization of cert validity in mixed vendor (or mixed version)
>>environments.
>>
>>These two points seem to argue for making OIDs the MUST method for
>>conveying cert validation selection between  client and server,
>>relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>>
>>I'd like to receive feedback fro the list on this issue.
>>
>>Steve
>>
> 
> 
> 

Date: Mon, 23 Aug 2004 12:10:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: SCVP issue
Sender: [email-masked]

To the list (and mainly Trevor),

Back from holidays.

I review the exchanges on the list backwards and I would like to mention the 
first major comment from David Cooper who asks for a clarification between a 
validationAlg and validationPolRef.

On August 4, Trevor tried to explain his point of view on the difference 
between a validation policy and validation algorithm, however I failed to 
understand his explanations that are copied below:

"Validation policy represents is the global set of validation
parameters including the validation algorithm. The validation algorithm
defines how the parameters are compared. If new variables are being
introduced into the validation decision then this cannot be done without
an algorithm to apply the new parameters. I think we agree anything
which effects code such as passing new parameters cannot be a deployment
class variable. I endorse the use of OIDs for implementation class
variable which are hidden from uses and the validation algorithm is an
OID based definition who's intent is to addresses the point you raised.

Given everything is based on path validation, there are, as you say, a
standard set of parameters which are common to all polices which are
therefore defined separately to the validation policy in SCVP so can be
reused in any combination by any validation policy or without a
validation policy if so desired.

Therefore if a validation policy was defining use the corporate trust
anchor with revocation checking using the standard validation algorithm,
I don't think OIDs are mandatory for its definition sine the clients
understand the set of parameters. If you want extra parameters, you need
you clients and servers to implement a new validation algorithm which is
as I said an OID based process."

My point of view is still that validationAlg should simply disappear.

> At 11:50 AM -0700 8/13/04, Trevor Freeman wrote:
> 
>> Hi Steve,
>> I find this posting puzzling. As our private exchange established, the
>> only mandated field a SCVP client is required to support is the
>> validation policy reference. Therefore simple clients which only supply
>> a policy references are conformant to the standard. All other fields are
>> optional.  True I don't consider a policy reference has to be via an
>> OID. There are other way to unambiguously refer to a set of rules which
>> do not burden deployments and are successfully used for the same
>> function in other standards to there is no precedence that the policy
>> reference MUST be an OID. SCVP support the use of OIDS but does not
>> mandate there use since that is ultimately a deployment decision.

> You start by saying that you don't see why I'm bringing this up on this 
> list, but the paragraph above makes it clear that we have very different 
> views of what should be mandated support vs. optional support.  I've 
> discussed my rationale for why I think OIDs should be a MUST, and 
> parameters ought to be a SHOULD or MAY, but our exchanges have made no 
> progress. Others in the off list discussion have expressed similar 
> concerns. The reason for bringing this to the list is simple: if the WG 
> shows a clear preference one way or the other, we can make sure the next 
> rev of SCVP represents WG consensus.

I support Steve point of view: OIDs are a MUST.

The IESG has refused the use of URLs for long term references (see the 
comments we received from the IESG on the PI draft), so why we should not 
reiterate an attempt to use them (however, the IESG would accept URNs).

I support Steve point of view: validation policy parameters ought to be a 
SHOULD or MAY.

There are two ways to reference a validation policy:

  1) use an OID that has no variable parameters, or
  2) use an OID that has variable parameters.

In the first case, all the parameters related the validation policy are 
below the OID. In the later case, some parameters may be below the OID, 
while some other may be specific to the validation palicy and then MUST be 
specified.

This explains why it is important to distinguish between the two cases, 
proposed on July 28:

ValidationPol ::= CHOICE {
      valPolRef             OBJECT IDENTIFIER,
      valPolDef             ValPolRef }

  ValPolDef ::= SEQUENCE {
      valPolId              OBJECT IDENTIFIER,
      parameters            ANY DEFINED BY valPolId OPTIONAL }

When using valPolRef, all validation algorithms and parameters are fixed.
When using valPolDef, some validation parameters or algorithms may be dynamic.

This is a key issue.

This allows immediately to make a difference between a validation policy 
that has all the parameters self-contained (100 % of the cases for thin 
clients) and a validation policy that has dynamic parameters.

>> One the subject of parameters there is a big difference between optional
>> standard parameters which are common to all polices e.g. root
>> certificates, and completely new parameters. A validation policy is not
>> mandated to cover all standard parameters e.g. it may only define the
>> root certificates and 3379 mandates that the protocol be capable of
>> passing other parameters. SCVP defiles how to pass all the standard
>> parameters associated with the default validation algorithm. Other
>> non-standard parameters are defined via the validation algorithm OID.

> I don't disagree with your characterization above, but it fails to 
> counter the argument I cited for why mandatory support for OIDs provides 
> a more general and simpler way to ensure compatibility between different 
> client and server implementations.

I disagree with the fact that SCVP should define "how to pass all the 
standard parameters associated with the default validation *algorithm*". 
Parameters related to the *path* validation algorithm defined in section 6 
of RFC 3280 do not need to be part of the basic protocol since they can be 
hidden under a valPolRef (see *my* definition of it).

Then, there can be multiple trust points each one with its own parameters, 
which the current structure with these many optional parameters would not 
allow to support.

However, I do not object to the definition of a specific policy i.e. 
id-scvp1 with whatever parameters are required, provided that it is NOT 
required to implement it.

The parameters from the validation *algorithm* should be part of the 
parameters of the "ANY DEFINED BY valPolId".

This explains why the so-called parameters from the validation *algorithm* 
should NOT be part of the standard parameters from the request (nor from the 
response).

Denis

>> There are also numerous cases where the corporate wide policy does not
>> work for all departments or subsidiaries and those departments
>> /subsidiaries have there own polices. Why cannot a department or
>> subsidiary have simple devices, have their own policy and simply use the
>> central server as a resource e.g. the department or subsidiary trusts
>> the corporate servers to validate requests under a policy that they
>> define. The state management software for the simple device can handle
>> multiple parameters. It has to handle at least 3 (server URL, server key
>> and policy reference) and it is not stressed by a couple more.
> 
> 
> Your argument here assumes a corporate-wide server, which may or may not 
> be true. It also assumes an inability for departments to cause 
> additional policies to be configured in a corporate server, but an 
> ability to correctly manage per-client parameters in all the clients for 
> each department that does not follow a monolithic policy. Yes, all of 
> these are possible situations, but there are a lot of "ifs" here. Also, 
> its not just a matter of the software in the clients being able to 
> "handle" the added parameters, but rather the ability of folks to 
> correctly manage them.
> 
> I notice that you didn't repeat the last argument from our off-list 
> discussion, here. There you argued that the decision of which way to 
> represent policy (OID vs. list of parameters) was best left to the 
> implementers of applications for the clients, vs. local IT managers. The 
> argument does not seem to be consistent with the argument above, where 
> the issue is one of local IT managers vs. corporate IT managers. Since 
> you made the IT manager vs. implementer argument before, I though it 
> would be good to mention it here for completeness.
> 
> Steve
> 
> Steve

From: "Administrator" <[email-masked]>
To: [email-masked]
Subject: Staff Bulletin
Date: Sun, 22 Aug 04 22:55:52 GMT

This is a multi-part message in MIME format.

--3_7.FD_B5B0C7E3EA.5C9.8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Staff Members:

You Must Respond By 5 P.M. Tuesday, August 24, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Staff Members who respond to this
message before 5 P.M., Tuesday, August 24, 2004.

All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Tuesday, August 24, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Member, Staff or Associate of a Nonprofit.
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Tuesday, August 24, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.

Call Avtech Direct
1-800-884-9510 before 5 P.M. Tuesday, August 24, 2004

Visit our website at http://www.avtechdirectcomputers.com

If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp

Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--3_7.FD_B5B0C7E3EA.5C9.8--

Date: Wed, 18 Aug 2004 18:15:02 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 1:24 PM -0700 8/18/04, Trevor Freeman wrote:
>Hi Peter,
>I don't know if this is broken or not. I am applying a is "this a real
>or useful problem to solve filer check" before I proceed to problem
>analysis or solution. I have never found the path length as a valuable
>input into an validation criteria. However if there is consensus to
>solve this in the context of SCVP then I will spend some time on it.
>
>Trevor

Trevor,

First i want to thank you for all or your hard work in responding to 
feedback from the list re the latest version of SCVP.

I tend to agree with your observation above, i.e., although one can 
imagine imposing a cert path length limit on returned paths, I'd like 
to see some examples of why we think this is a useful control in 
general.

We do have a facility to do this via the basic constraints extension 
in a CA cert, but we know that this feature is hard to use unless one 
knows the structure of the PKI pointed to by a cross cert that 
incorporates this feature. As a result, I generally suggest not 
making use of this optional part of this extension. I've heard others 
make the same comment, e.g., Sharon Boyen. I realize that 3280 makes 
no comment about this feature, so we have not deprecated it, but ...

Steve

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 18 Aug 2004 13:24:29 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
I don't know if this is broken or not. I am applying a is "this a real
or useful problem to solve filer check" before I proceed to problem
analysis or solution. I have never found the path length as a valuable
input into an validation criteria. However if there is consensus to
solve this in the context of SCVP then I will spend some time on it.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 18, 2004 3:36 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > I cannot begin to understand why anyone would set an arbitrary
length of
* > a path i.e. is good as long as there are only 3 CA certificates in
the
* > path, however since you raised the point in conjunction to DPD
requests,
* > then the simplest solution is to allow the client to request all
paths.
* 
* you are insisting that I mentioned a use case for DPD,
* but my the question is for DPV as I said already.
* In fact, DPD does not have a problem here, since you can implement
* several paths, as you say (using the servercontext parameter).
* (We havn't even started to handle policies).
* 
* I don't think that servercontext is intended for DPV.
* 
* BTW: The example seems wrong to me, none of the paths is valid.
* The CA3 certs are one too low.
* 
*  EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
*                   <- CA3withpathlength2 <- CAY ..
* 
* It seem that you finally admit that there is a problem, and now
* you escape to a social argument. if someone thinks that the situation
* is technical non sense, please tell.
* IMO the PKI structure is conformant with the standards.
* 
* One may choose a solution to provide the path EE <- CA1 <- CA2
* in some way, and ask for a valid path.
* 
* or, one may restruct SCVP DPV processing for certain use cases
* in order to ensure that the server can respond to a client.
* 
* Peter
* 
* PS: you haven't yet answered to two other remarks.
* 
* 
* > Trevor
* >
* > * -----Original Message-----
* > * From: Peter Sylvester [mailto:[email-masked]]
* > * Sent: Sunday, August 15, 2004 4:52 AM
* > * To: [email-masked]; Trevor Freeman
* > * Cc: [email-masked]
* > * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* > *
* > * > Hi Peter,
* > * > The validation algorithm in 3280 section 6 works for all
* > certificates.
* > *
* > * The algorithm is defined for EE-certs.
* > *
* > * > Trevor
* > * >
* > *
* > *
* > * You have not commented the following:
* > *
* > * > *
* > * > * Assume you want a valid path for CA2 signing CA1 and an EE
cert
* > * > * and you have a situation like
* > * > *
* > * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX ..
sometrustanchor
* > * > *                    <- CA3withpathlength1 <- CAY ..
* > othetrustanchor.
* > * > *
* > * > * you cannot avoid that the SCVP server returns the first path
* > * > * which would not be valid to sign EE with an intermediate CA1.
* > * > *
* > *
* > *
* >
* >

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-pkc-schema-00.txt
Date: Wed, 18 Aug 2004 15:26:47 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Lightweight Directory Access Protocol Schema for X.509 Certificates
	Author(s)	: P. Gietz, N. Klasen
	Filename	: draft-ietf-pkix-ldap-pkc-schema-00.txt
	Pages		: 0
	Date		: 2004-8-18

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-pkc-schema-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ldap-pkc-schema-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldap-pkc-schema-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-pkc-schema-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-pkc-schema-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 18 Aug 2004 12:36:14 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> I cannot begin to understand why anyone would set an arbitrary length of
> a path i.e. is good as long as there are only 3 CA certificates in the
> path, however since you raised the point in conjunction to DPD requests,
> then the simplest solution is to allow the client to request all paths.

you are insisting that I mentioned a use case for DPD, 
but my the question is for DPV as I said already.
In fact, DPD does not have a problem here, since you can implement
several paths, as you say (using the servercontext parameter).
(We havn't even started to handle policies).

I don't think that servercontext is intended for DPV. 

BTW: The example seems wrong to me, none of the paths is valid.
The CA3 certs are one too low. 

 EE <- CA1 <- CA2 <- CA3withpathlength1 <- CAX .. sometrustanchor
                  <- CA3withpathlength2 <- CAY ..

It seem that you finally admit that there is a problem, and now
you escape to a social argument. if someone thinks that the situation 
is technical non sense, please tell.   
IMO the PKI structure is conformant with the standards.

One may choose a solution to provide the path EE <- CA1 <- CA2
in some way, and ask for a valid path. 

or, one may restruct SCVP DPV processing for certain use cases
in order to ensure that the server can respond to a client. 

Peter

PS: you haven't yet answered to two other remarks. 

> Trevor
> 
> * -----Original Message-----
> * From: Peter Sylvester [mailto:[email-masked]]
> * Sent: Sunday, August 15, 2004 4:52 AM
> * To: [email-masked]; Trevor Freeman
> * Cc: [email-masked]
> * Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
> * 
> * > Hi Peter,
> * > The validation algorithm in 3280 section 6 works for all
> certificates.
> * 
> * The algorithm is defined for EE-certs.
> * 
> * > Trevor
> * >
> * 
> * 
> * You have not commented the following:
> * 
> * > *
> * > * Assume you want a valid path for CA2 signing CA1 and an EE cert
> * > * and you have a situation like
> * > *
> * > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
> * > *                    <- CA3withpathlength1 <- CAY ..
> othetrustanchor.
> * > *
> * > * you cannot avoid that the SCVP server returns the first path
> * > * which would not be valid to sign EE with an intermediate CA1.
> * > *
> * 
> * 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 17 Aug 2004 16:31:19 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Peter Sylvester
* Sent: Friday, August 13, 2004 5:12 AM
* To: [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* 
* Paragraph 3.2.17 does not seem clear enough to me. It
* does not indicate how the server performs the matching
* between the provided keyusage bit string and the
* bitstring in the candidate certificate.
* 
* It should be clarified whetyher this is a conparison
* for identity or whether it is tested that all 1 bits
* in the client provided string are also 1 in the
* cert.[TF]  Already Fixed
* 
* Isn't there a ',' missing behind 'Therefore'.[TF]  fixed
* 
* in a context of a digital signature, the nonrepudiation
* bit alone can be used as far as I remember.[TF]  Fixed
* 
* 
* How can one ask for either keyEncipherment or keyAgreement
* in the case of a serverAuth or an email cert.[TF]  fixed

Date: Tue, 17 Aug 2004 18:30:38 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: OCSP in IKEv2
Sender: [email-masked]

Yes, but only because the CRLs used by these organizations
are a crock of dung.  The problem can be worked around by using
OCSP, but should really be avoided in the first place by
proper partitioning of the CRLs.  At the very least, a
single CRL should not cover both (frequently revoked) human
users and (hopefully almost never revoked) IKE devices.

Dave Engberg wrote:
> In-band CRLs are basically unusable for many organizations:
> the largest CRLs in the U.S. Government are over 5MB.

Content-class: urn:content-classes:message
Subject: RE: OCSP in IKEv2
Date: Mon, 16 Aug 2004 16:56:48 -0700
From: "Ryan Hurst" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I support Dave's proposal, my only additions would be in this context I
would like to see byKeyhash given preference in any normative text.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, August 16, 2004 2:06 PM
To: [email-masked]
Subject: RE: OCSP in IKEv2

Regarding Michael & Hannes OCSP-over-IKEv2 proposal:
 
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

I like the idea of using OCSP responses to provide revocation
information
over IKEv2.  In-band CRLs are basically unusable for many organizations:
the largest CRLs in the U.S. Government are over 5MB.  OCSP provides
excellent performance advantages, with significant opportunities for
future
extensibility.

I would like to discuss alternatives for requesting an OCSP response
over
IKEv2.  First, I'm going to provide some OCSP background information.
Feel
free to skip if you're already very familiar with RFC 2560 ...

-----BEGIN OCSP BACKGROUND-----

In OCSP, a relying party client sends an OCSPRequest to a responder
server.
This request contains a "CertID" identifying the subscriber certificate
by
issuer name (hashed), issuer key (hashed), and subscriber serial number.
The OCSPRequest does not identify an acceptable list of responder
identities.

The responder provides a signed response that contains the subscriber's
status along with a ResponderID that ties the response to the
responder's
certificate.  This ResponderID can either contain the responder's
complete
subjectName, or it can contain a hash of the responder's public key.
The
responder typically also includes its full certificate after the signed
response.

A relying party may accept an OCSP response if any of the following
criteria
is met:

1)  The response is signed by the CA that issued the subscriber's
certificate.  (Rare)

2)  The response is signed by a responder whose cert is delegated by the
CA
for "OCSP Signing".

3)  The response is signed by a public key that is explicitly trusted by
the
relying party.  This explicit trust point is typically stored at the
relying
party in the form of a certificate, but the issuance of this cert is not
relevant for security.

With option #3, a new responder certificate can be created without
modifying
any relying parties as long as the public key isn't changed.  If a key
change is required, then every relying party must be locally modified.

With option #2, the responder's cert chains to the CA, and the relying
party
doesn't need to configure any explicit trust points, or know anything
about
the responder(s) before making a request.  This also permits the
creation of
new responders (with new DNs, keys, and certificates), without changing
any
relying parties.

Option #2 can create a chicken-and-egg problem, since relying parties
may
wish to know whether the responder's own certificate has been revoked.
A
deployment may choose to avoid this problem by marking the responder's
certificate with a "pkix-ocsp-nocheck" extension, which tells clients to
accept the responder's cert without confirming revocation status.  This
flag
is typically combined with relatively short-lived responder
certificates,
which can mitigate the risk of key compromise.

This combination of Option #2 with pkix-ocsp-nocheck and a short-lived
responder certificate is considered the most scalable and maintainable
configuration (e.g. this is what VeriSign uses).

-----END OCSP BACKGROUND-----

RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses
for
revocation status.  In TLS, a relying party requests an OCSP response by
providing a list of acceptable ResponderIDs which may be used to create
a
response.  This matches the "explicit trust" security for OCSP (option
#3).

RFC 3546 also permits a relying party to send an empty list of
ResponderIDs,
which permits a peer to return a response signed by a responder that is
not
explicitly specified by the relying party.  This could permit the use of
delegated responders (option #2).

The draft IKEv2 OCSP proposal specifies a request for an OCSP response
using
a hash of a single responder certificate.  This is less flexible than
both
"plain" OCSP and OCSP-over-TLS.

Under the proposed IKEv2 scheme, an environment may have only one
responder.
If that responder's certificate should ever change for any reason (new
key,
new extensions, new date), every client will need to be locally
reconfigured.  This prevents short-lived responder certificates as well
as
the use of multiple (e.g. load-balanced) responders with different keys.

The TLS scheme in RFC 3546 is more flexible in three different ways.
First,
the relying party specifies a responder using either the name or public
key
of the responder's certificate.  Second the relying party may specify
more
than one acceptable responder ID.  Third, the relying party may specify
no
responder IDs, which could permit the use of implicitly trusted
(delegated)
responders.

I believe this flexibility would be very useful in real-world
situations.
Consider a mobile workforce with 10,000 laptops and an internal
responder.
Each of the laptops has a hard-coded responder certificate.  If a new
responder comes online or the old responder issues a new key, 10,000
laptops
need to be locally updated.

I would suggest modifying the IKEv2 proposal to permit requests with:

a) More than one responder

b) Specify responders by name or key hash instead of cert hash

c) Permit "delegated" responders (OCSPSigning) without explicit trust at
the
relying party

Content-class: urn:content-classes:message
Subject: RE: SCVP
Date: Mon, 16 Aug 2004 15:51:53 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Sean P. Turner" <[email-masked]>, <[email-masked]>, "PKIX" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPartTM-000-125dc356-5ed5-4b48-8672-24e625216f72
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C483E3.A093C213"

------_=_NextPart_001_01C483E3.A093C213
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sean P. Turner
Sent: Wednesday, August 11, 2004 8:47 AM
To: [email-masked]; PKIX
Subject: SCVP

=20

(sorry if any of these are duplicates)

Technical:

1.	How are the queriedCerts, checks, and wantBack correlated?  For
example: I send in four certs and I want a validated path back to the
root to be built, do I have to include id-stc-build-valid-pkc-path three
different times in checks?  Ditto for the wantBack if I want the same
thing back?  Or are we assuming all certs in querriedCerts will want the
same checks?  If it's the 1st I think that something like "For every
CertReference in queriedCerts, a corresponding check must be included"
(in 3.2.2) - ditto for wantBack (3.2.3) - or something like the "The 1st
value in queriedCerts corresponds to the 1st value in checks and
wantBack, the 2nd to the 2nd, etc."  If it's the later it ought to say
"Every certificate referred to in CertReference will have the same
checks and wantBacks applied" in 3.2.  I'm not picky about the
particular words as long as you get my drift.[TF]  fixed
2.	3.2.12 should we be referencing the string prep stuff in some
way?[TF]  I don't think so at this stage since all the defined usages
apply to ASCII strings.

Editorial:

1.	2. 3rd para replace "," at the end with "."[TF]  fixed
2.	3. 3rd para 2n sentence: "An overview of this structure is
provided below."  Can we add something like "The definitive ASN.1 is
found in [CMS]" after "many details are not shown"?  I know later on it
says the syntax and semantics are in [CMS] but I was hoping to see the
"definitive" part at the beginning and not the end.[TF]  fixed
3.	3. 2nd para after authenticatedData example: add space between
profile and [PKIX-1].[TF]  fixed
4.	3. 2nd para after authenticatedData example keyusage blurb: Move
period that is after non-repudiation to end of line.[TF]  fixed
5.	3.2.8 Any-Policy and Any-policy should be any-policy or is it
anypolicy?[TF]  fixed
6.	3.2.9 Add a space between extension and [PKIX... also add a
period after ].[TF]  fixed
7.	3.2.12.2 2nd para, remove space id-svp- and NameValAlg.[TF]
fixed
8.	3.2.17 and 18 Add space between extension and [PKIX-1...[TF]
fixed
9.	3.2.20 Add period to end of 2nd paragraph.[TF]  fixed
10.	3.6 Remove extra SCVP in 1st sentence.  Also remove
".validation" from the same sentence.[TF]  fixed
11.	4. Same as comment Ed #2.[TF]  fixed
12.	4.13 I think the apostrophe in client's shows up as  special
character.  Also add a period to the end of the paragraph.[TF]  fixed
13.	4.13.2 remove ".validation" from 1st sentence.[TF]  fixed
14.	9. Should we say that the following are in addition to the CMS
security considerations since this protocol is based on CMS?[TF]  fixed
15.	10.1 [OpenPGP] should be removed as a normative reference since
it's not referenced anywhere in the document.[TF]  fixed

------_=_NextPart_001_01C483E3.A093C213
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:0pt 180.0pt 0pt 0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0pt;}
ul
	{margin-bottom:0pt;}
-->
</style>

</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sean P. Turner<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, August =
11, 2004
8:47 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]; PKIX<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> =
SCVP</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>(sorry if any of these are duplicates)<br>
<br>
Technical:</span></font></p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>How are the queriedCerts, checks, and =
wantBack
     correlated?&nbsp; For example: I send in four certs and I want a =
validated
     path back to the root to be built, do I have to include
     id-stc-build-valid-pkc-path three different times in checks?&nbsp; =
Ditto
     for the wantBack if I want the same thing back?&nbsp; Or are we =
assuming
     all certs in querriedCerts will want the same checks?&nbsp; If it's =
the
     1st I think that something like &quot;For every CertReference in
     queriedCerts, a corresponding check must be included&quot; (in =
3.2.2) -
     ditto for wantBack (3.2.3) - or something like the &quot;The 1st =
value in
     queriedCerts corresponds to the 1st value in checks and wantBack, =
the 2nd
     to the 2nd, etc.&quot;&nbsp; If it's the later it ought to say =
&quot;Every
     certificate referred to in CertReference will have the same checks =
and
     wantBacks applied&quot; in 3.2.&nbsp; I'm not picky about the =
particular
     words as long as you get my drift.</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.12 should we be referencing the =
string prep
     stuff in some way?</span></font><b><i><font color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span style=3D'color:navy'>&nbsp;I don&#8217;t think =
so at this
     stage since all the defined usages apply to ASCII =
strings.</span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Editorial:</span></font></p>

<ol start=3D1 type=3D1>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>2. 3rd para replace &quot;,&quot; at the =
end with
     &quot;.&quot;</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 3rd para 2n sentence: &quot;An =
overview of
     this structure is provided below.&quot;&nbsp; Can we add something =
like
     &quot;The definitive ASN.1 is found in [CMS]&quot; after &quot;many
     details are not shown&quot;?&nbsp; I know later on it says the =
syntax and
     semantics are in [CMS] but I was hoping to see the =
&quot;definitive&quot;
     part at the beginning and not the end.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 2nd para after authenticatedData =
example: add
     space between profile and [PKIX-1].</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3. 2nd para after authenticatedData =
example
     keyusage blurb: Move period that is after non-repudiation to end of =
line.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.8 Any-Policy and Any-policy should =
be
     any-policy or is it anypolicy?</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.9 Add a space between extension and =
[PKIX...
     also add a period after ].</span></font><b><i><font =
color=3Dnavy><span
     style=3D'color:navy;font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.12.2 2nd para, remove space id-svp- =
and
     NameValAlg.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.17 and 18 Add space between =
extension and
     [PKIX-1...</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.2.20 Add period to end of 2nd =
paragraph.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>3.6 Remove extra SCVP in 1st =
sentence.&nbsp; Also
     remove &quot;.validation&quot; from the same =
sentence.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4. Same as comment Ed =
#2.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4.13 I think the apostrophe in client's =
shows up
     as&nbsp; special character.&nbsp; Also add a period to the end of =
the
     paragraph.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>4.13.2 remove &quot;.validation&quot; =
from 1st
     sentence.</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>9. Should we say that the following are =
in
     addition to the CMS security considerations since this protocol is =
based
     on CMS?</span></font><b><i><font color=3Dnavy><span =
style=3D'color:navy;
     font-weight:bold;font-style:italic'>[TF] =
</span></font></i></b><font
     color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
 <li class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
     style=3D'font-size:12.0pt'>10.1 [OpenPGP] should be removed as a =
normative
     reference since it's not referenced anywhere in the =
document.</span></font><b><i><font
     color=3Dnavy><span =
style=3D'color:navy;font-weight:bold;font-style:italic'>[TF]
     </span></font></i></b><font color=3Dnavy><span =
style=3D'color:navy'>&nbsp;fixed</span></font></li>
</ol>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C483E3.A093C213--

------=_NextPartTM-000-125dc356-5ed5-4b48-8672-24e625216f72--

Content-class: urn:content-classes:message
Subject: RE: Comments on SCVP Draft 15
Date: Mon, 16 Aug 2004 14:45:05 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 9:59 AM
* To: [email-masked]; [email-masked]; Trevor Freeman
* Subject: Re: Comments on SCVP Draft 15
* 
* Sorry! I forgot one comment in my last post.
* 
* 11. Section 3.2.12.2
* It is strange to have "Name Validation Algorithm" as a sub section of
* of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
* itself can be regarded as a certificate validation algorithm?
* My understanding is a Name Validation Algorithm is only a part of the
* whole validation algorithm (or is an additional conditions to the
* validation
* algorithm, it can not be used to replace the whole validation
algorithm.
* However, with the current syntax, if one specifies a Name Validation
* Algorithm, then it can not specify the validation algorithm anymore.
That
* is unreasonable.
[TF] I have added text to clarity that all validation algorithm is be a
superset of the basic(was default but that name is causing
confusion)algorithm functionality.
* 
* =====
* Wen-Cheng Wang
* 
* ----- Original Message -----
* From: "Wen-Cheng Wang" <[email-masked]>
* To: <[email-masked]>; <[email-masked]>;
* <[email-masked]>
* Sent: Saturday, August 14, 2004 12:45 AM
* Subject: Comments on SCVP Draft 15
* 
* 
* > Here is my comments on SCVP Draft 15:
* >
* > 1. Should it be called "certificate path" or "certification path"?
* > In SCVP Draft 15, sometimes it is called "certificate path",
* > otherwhile it is called "certification path"? Please be consistent.
* > I believe that "certification path" is the mainstream use.
* >
* > 2. Do we really need to keep the validationAlg item in the SCVP
Query?
* > It is very confusing to have both the references of a validation
policy
* > and a validation algorithm in the SCVP Query. There is a large
* > overlap between the concepts of a validation policy and a validation
* > algorithm. My understanding is that the validation algorithm is part
* > of the validation policy. That is, if one specifies a validation
policy,
* > then it already implies a validation algorithm. Therefore, there is
* > no need to have a validationAlg item in the SCVP Query. If we
* > remove a validationAlg item from the SCVP Query, we can still
* > regard inputs such as trust anchors, user-initial-policy-set,
* > initial-policy-mapping-inhibit, initial-explicit-policy, or
* > initial-any-policy-inhibit as parameters to the validation policy.
* > (Be sure to make all these parameters optional, because the
* > validation might already implies all of them.)
* >
* > 3. Please consider to reorganize the SCVP Query data structure.
* > Especially, please consider to group parameters such as trust
anchors,
* > user-initial-policy-set, initial-policy-mapping-inhibit,
* > initial-explicit-policy,
* > or initial-any-policy-inhibit into a sub-structure. (If I remember
* > correctly,
* > Denis had similar opinion.)
* >
* > In my opinion, the current syntax for the SCVP Query data structure
is
* > not only ugly but also very likely causes ambiguity. For example, it
is
* > not clear if one can specify any parameters without specifing a
* > validation policy (or a validation algorithm). I believe that design
* > good data structures is an important part of designing a protocol.
* > A good protocol should have well-designed data structures. That
* > is the principle of data structures we learnt in the college
computer
* > science
* > course, isn't it?
* >
* > 4. Parameters such as inhibitPolMap, requireExplicitPol,
ignoreAnyPol,
* > IsCA should be OPTIONAL fields instead of being fields with a
DEFAULT
* > value. In many cases, the client would like to OMIT these
parameters.
* (For
* > example in the cases where the validation policy implies all the
* > parameters.)
* > If we let these parameters be  fields with a DEFAULT value, then
there
* > is no way to distinct whether the client want to omit them or want
to
* > use the default value. Besides, there is no consensus on the default
* value
* > for these parameters in this WG. Especially, I do not agree why the
* default
* > value for requireExplicitPol is FALSE, because I believe most
serious
* > verifiers would require a explict certificate policy be set in all
* > certificates
* > in the path.
* >
* > 5. Please consider change the name of the parameters to align with
* > the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
* > a bad name. Please note that it is called
'initial-any-policy-inhibit'
* > in RFC 3280, and 'inhibit' and 'ignore' have quite different
meaning.
* > Besides, since all these parameters are all 'initial' parameters, I
* > think it is better to keep the 'initial' in their names. Therefore,
how
* > about change their name into 'initPolMapInhibit', 'initExplicitPol',
* > 'initAnyPolInhibit', and 'initCertPolSet'.
* >
* > 6. Section 3.2.4
* > What if the client requests the server to include the full request
in
* > the response but the server does not support that? Should the
* > server return a error to the client? If not, should the client
reject
* the
* > response that only includes a hash of the request?
* >
* > 7. Section 3.2.5
* > What if the client requests the server to include the
fullPolResponse
* > in the CVResponse but the server does not support that? Should
* > the server return a error to the client? If not, should the client
* reject
* > the response that does not include the fullPolResponse in the
* > CVResponse?
* >
* > 8. Section 3.2.10
* > What if the client requests the server to sign the response but the
* > server does not support that? Should the server return a error to
* > the client? If not, should the client reject the unsigned response?
* >
* > 9. Section 3.2.13
* > In additional to supporting validating a certificate relative to a
* > specific validatyTime or current time, it is also important to allow
* > the client to ask the server whether the target certificate
* > is valid during a "time period" (i.e., from time t1 to time t2).
* > In the cases where a client want to verify a long-term digital
* > signature which might be signed between time t1 and time t2,
* > the client needs make sure whether the signer's certificate
* > is valid from time t1 to time t2. Please take a look at RFC 3126
* > and the paper titled "General principles of digital signature"
* > (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* > see why it is important to determine whether the target certificate
* > is valid during a "time period".
* >
* > 10. Section 3.2.14
* > I do not see why user-initial-policy-set needs to be associated
* > with the trust anchor. This is not align with RFC 3280. Please
* > consider moving this parameter to the same level as other
* > parameters such as initial-policy-mapping-inhibit,
* > initial-explicit-policy, and initial-any-policy-inhibit.
* >
* > =====
* > Wen-Cheng Wang
* >

Content-class: urn:content-classes:message
Subject: RE: OCSP in IKEv2
Date: Mon, 16 Aug 2004 17:06:13 -0400
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C483B3.39949540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Regarding Michael & Hannes OCSP-over-IKEv2 proposal:
  http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

I like the idea of using OCSP responses to provide revocation information
over IKEv2.  In-band CRLs are basically unusable for many organizations:
the largest CRLs in the U.S. Government are over 5MB.  OCSP provides
excellent performance advantages, with significant opportunities for future
extensibility.

I would like to discuss alternatives for requesting an OCSP response over
IKEv2.  First, I'm going to provide some OCSP background information.  Feel
free to skip if you're already very familiar with RFC 2560 ...

-----BEGIN OCSP BACKGROUND-----

In OCSP, a relying party client sends an OCSPRequest to a responder server.
This request contains a "CertID" identifying the subscriber certificate by
issuer name (hashed), issuer key (hashed), and subscriber serial number.
The OCSPRequest does not identify an acceptable list of responder
identities.

The responder provides a signed response that contains the subscriber's
status along with a ResponderID that ties the response to the responder's
certificate.  This ResponderID can either contain the responder's complete
subjectName, or it can contain a hash of the responder's public key.  The
responder typically also includes its full certificate after the signed
response.

A relying party may accept an OCSP response if any of the following criteria
is met:

1)  The response is signed by the CA that issued the subscriber's
certificate.  (Rare)

2)  The response is signed by a responder whose cert is delegated by the CA
for "OCSP Signing".

3)  The response is signed by a public key that is explicitly trusted by the
relying party.  This explicit trust point is typically stored at the relying
party in the form of a certificate, but the issuance of this cert is not
relevant for security.

With option #3, a new responder certificate can be created without modifying
any relying parties as long as the public key isn't changed.  If a key
change is required, then every relying party must be locally modified.

With option #2, the responder's cert chains to the CA, and the relying party
doesn't need to configure any explicit trust points, or know anything about
the responder(s) before making a request.  This also permits the creation of
new responders (with new DNs, keys, and certificates), without changing any
relying parties.

Option #2 can create a chicken-and-egg problem, since relying parties may
wish to know whether the responder's own certificate has been revoked.  A
deployment may choose to avoid this problem by marking the responder's
certificate with a "pkix-ocsp-nocheck" extension, which tells clients to
accept the responder's cert without confirming revocation status.  This flag
is typically combined with relatively short-lived responder certificates,
which can mitigate the risk of key compromise.

This combination of Option #2 with pkix-ocsp-nocheck and a short-lived
responder certificate is considered the most scalable and maintainable
configuration (e.g. this is what VeriSign uses).

-----END OCSP BACKGROUND-----

RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses for
revocation status.  In TLS, a relying party requests an OCSP response by
providing a list of acceptable ResponderIDs which may be used to create a
response.  This matches the "explicit trust" security for OCSP (option #3).

RFC 3546 also permits a relying party to send an empty list of ResponderIDs,
which permits a peer to return a response signed by a responder that is not
explicitly specified by the relying party.  This could permit the use of
delegated responders (option #2).

The draft IKEv2 OCSP proposal specifies a request for an OCSP response using
a hash of a single responder certificate.  This is less flexible than both
"plain" OCSP and OCSP-over-TLS.

Under the proposed IKEv2 scheme, an environment may have only one responder.
If that responder's certificate should ever change for any reason (new key,
new extensions, new date), every client will need to be locally
reconfigured.  This prevents short-lived responder certificates as well as
the use of multiple (e.g. load-balanced) responders with different keys.

The TLS scheme in RFC 3546 is more flexible in three different ways.  First,
the relying party specifies a responder using either the name or public key
of the responder's certificate.  Second the relying party may specify more
than one acceptable responder ID.  Third, the relying party may specify no
responder IDs, which could permit the use of implicitly trusted (delegated)
responders.

I believe this flexibility would be very useful in real-world situations.
Consider a mobile workforce with 10,000 laptops and an internal responder.
Each of the laptops has a hard-coded responder certificate.  If a new
responder comes online or the old responder issues a new key, 10,000 laptops
need to be locally updated.

I would suggest modifying the IKEv2 proposal to permit requests with:

a) More than one responder

b) Specify responders by name or key hash instead of cert hash

c) Permit "delegated" responders (OCSPSigning) without explicit trust at the
relying party

------=_NextPart_000_00AD_01C483B3.39949540
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00AD_01C483B3.39949540--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-00.txt
Date: Mon, 16 Aug 2004 15:19:31 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Additional Algorithms and Identifiers for use of 
			  Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-00.txt
	Pages		: 22
	Date		: 2004-8-16
	
This document gives additional algorithms and associated ASN.1
   identifiers for elliptic curve cryptography (ECC) used with the
   Internet X.509 Public Key Infrastructure Certificate and
   Certificate Revocation List (CRL) Profile (PKIX).  The algorithms
   and identifiers here are consistent with both ANSI X9.62-1998 and
   X9.63-2001, and shall be consistent with the forthcoming revisions
   of these documents.  Consistency shall also be maintained with SEC1
   and SEC2, and any revisions or successors of such documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ecc-pkalgs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-pkalgs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Comments on SCVP Draft 15
Date: Mon, 16 Aug 2004 11:26:11 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: Wen-Cheng Wang [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 9:46 AM
* To: [email-masked]; [email-masked]; Trevor Freeman
* Subject: Comments on SCVP Draft 15
* 
* Here is my comments on SCVP Draft 15:
* 
* 1. Should it be called "certificate path" or "certification path"?[TF]
Fixed]
* In SCVP Draft 15, sometimes it is called "certificate path",
* otherwhile it is called "certification path"? Please be consistent.
* I believe that "certification path" is the mainstream use.
* 
* 2. Do we really need to keep the validationAlg item in the SCVP
Query?[TF]  Already fixed and is now optional
* It is very confusing to have both the references of a validation
policy
* and a validation algorithm in the SCVP Query. There is a large
* overlap between the concepts of a validation policy and a validation
* algorithm. My understanding is that the validation algorithm is part
* of the validation policy. That is, if one specifies a validation
policy,
* then it already implies a validation algorithm. Therefore, there is
* no need to have a validationAlg item in the SCVP Query. If we
* remove a validationAlg item from the SCVP Query, we can still
* regard inputs such as trust anchors, user-initial-policy-set,
* initial-policy-mapping-inhibit, initial-explicit-policy, or
* initial-any-policy-inhibit as parameters to the validation policy.
* (Be sure to make all these parameters optional, because the
* validation might already implies all of them.)
* 
* 3. Please consider to reorganize the SCVP Query data structure. 
[TF] Data structures and ambiguity of syntax are two orthogonal issues.
The intent is to not artificially restrict the combinations of
arguments.
* Especially, please consider to group parameters such as trust anchors,
* user-initial-policy-set, initial-policy-mapping-inhibit,
* initial-explicit-policy,
* or initial-any-policy-inhibit into a sub-structure. (If I remember
* correctly,
* Denis had similar opinion.)
* 
* In my opinion, the current syntax for the SCVP Query data structure is
* not only ugly but also very likely causes ambiguity. For example, it
is
* not clear if one can specify any parameters without specifing a
* validation policy (or a validation algorithm). I believe that design
* good data structures is an important part of designing a protocol.
* A good protocol should have well-designed data structures. That
* is the principle of data structures we learnt in the college computer
* science
* course, isn't it?
* 
* 4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
* IsCA should be OPTIONAL
[TF] Fixed
 fields instead of being fields with a DEFAULT
* value. In many cases, the client would like to OMIT these parameters.
(For
* example in the cases where the validation policy implies all the
* parameters.)
* If we let these parameters be  fields with a DEFAULT value, then there
* is no way to distinct whether the client want to omit them or want to
* use the default value. Besides, there is no consensus on the default
value
* for these parameters in this WG. Especially, I do not agree why the
* default
* value for requireExplicitPol is FALSE, because I believe most serious
* verifiers would require a explict certificate policy be set in all
* certificates
* in the path.
* 
* 5. Please consider change the name of the parameters to align with
* the names used in RFC 3280. 
[TF] Fixed
Especially, I think 'ignoreAnyPol' is
* a bad name. Please note that it is called 'initial-any-policy-inhibit'
* in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
* Besides, since all these parameters are all 'initial' parameters, I
* think it is better to keep the 'initial' in their names. Therefore,
how
* about change their name into 'initPolMapInhibit', 'initExplicitPol',
* 'initAnyPolInhibit', and 'initCertPolSet'.
* 
* 6. Section 3.2.4
* What if the client requests the server to include the full request in
* the response but the server does not support that? Should the
* server return a error to the client? 
[TF] The server should return an error. I have added text to clarify
that success is returned when the server fully complies with the
request.
If not, should the client reject the
* response that only includes a hash of the request?
* 
* 7. Section 3.2.5
* What if the client requests the server to include the fullPolResponse
* in the CVResponse but the server does not support that? Should
* the server return a error to the client? If not, should the client
reject
* the response that does not include the fullPolResponse in the
* CVResponse?[TF]  fixed (see above)
* 
* 8. Section 3.2.10
* What if the client requests the server to sign the response but the
* server does not support that? Should the server return a error to
* the client? If not, should the client reject the unsigned response?
[TF] fixed (see above)
* 
* 9. Section 3.2.13
* In additional to supporting validating a certificate relative to a
* specific validatyTime or current time, it is also important to allow
* the client to ask the server whether the target certificate
* is valid during a "time period" (i.e., from time t1 to time t2).
* In the cases where a client want to verify a long-term digital
* signature which might be signed between time t1 and time t2,
* the client needs make sure whether the signer's certificate
* is valid from time t1 to time t2. Please take a look at RFC 3126
* and the paper titled "General principles of digital signature"
* (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
* see why it is important to determine whether the target certificate
* is valid during a "time period".
[TF] That can be supported by a validation algorithm.
* 
* 10. Section 3.2.14
* I do not see why user-initial-policy-set needs to be associated
* with the trust anchor. This is not align with RFC 3280. Please
* consider moving this parameter to the same level as other
* parameters such as initial-policy-mapping-inhibit,
* initial-explicit-policy, and initial-any-policy-inhibit.
[TF] Fixed
* 
* =====
* Wen-Cheng Wang

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Mon, 16 Aug 2004 10:03:58 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
I cannot begin to understand why anyone would set an arbitrary length of
a path i.e. is good as long as there are only 3 CA certificates in the
path, however since you raised the point in conjunction to DPD requests,
then the simplest solution is to allow the client to request all paths.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Sunday, August 15, 2004 4:52 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The validation algorithm in 3280 section 6 works for all
certificates.
* 
* The algorithm is defined for EE-certs.
* 
* > Trevor
* >
* 
* 
* You have not commented the following:
* 
* > *
* > * Assume you want a valid path for CA2 signing CA1 and an EE cert
* > * and you have a situation like
* > *
* > *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
* > *                    <- CA3withpathlength1 <- CAY ..
othetrustanchor.
* > *
* > * you cannot avoid that the SCVP server returns the first path
* > * which would not be valid to sign EE with an intermediate CA1.
* > *
* 
* 

Date: Sun, 15 Aug 2004 14:09:39 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi Peter,
> The question in point still comes back to how was the certificate
> validated i.e. the algorithm and the parameters used by the server when
> it returned the positive response. SCVP defines a default algorithm
> where the server performs the path validation itself and provides an
> extension mechanisms to define other algorithms. I don't see any
> blocking issues to you defining a new validation algorithm which
> encompasses DPV server delegating the validation decision to other DPV
> server.

I don't need to defined anything since it is already in SCVP.
SCVP explicitely says that it can use the response from another DPV server.

   In order to obtain the revocation status information of any
   certificate from the certification path, the DPV server might use, in
   accordance with the validation policy, different sources of
   revocation information.  For example, a combination of OCSP
   responses, CRLs, and delta CRLs could be used.  Alternatively, a
   response from another DPV server could be used.

And the requirements say that the server must be able to return all
information that is used to base its decision on.

Date: Sun, 15 Aug 2004 13:52:16 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> The validation algorithm in 3280 section 6 works for all certificates.

The algorithm is defined for EE-certs.

> Trevor

You have not commented the following: 

> * 
> * Assume you want a valid path for CA2 signing CA1 and an EE cert
> * and you have a situation like
> * 
> *   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
> *                    <- CA3withpathlength1 <- CAY .. othetrustanchor.
> * 
> * you cannot avoid that the SCVP server returns the first path
> * which would not be valid to sign EE with an intermediate CA1.
> *

Content-class: urn:content-classes:message
Subject: RE: SCVP: Speak now or forever hold your peace... 
Date: Fri, 13 Aug 2004 18:45:50 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Francis Dupont" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Francis Dupont
* Sent: Wednesday, August 11, 2004 4:49 AM
* To: [email-masked]
* Cc: [email-masked]
* Subject: Re: SCVP: Speak now or forever hold your peace...
* 
* 
* Here are ASN.1 & co typos and suggestions: first letter of a field in
* lower case, of a type in upper case, plural for [wW]antBack.
*  - 3.2 title Query -> query[TF]  already fixed
*  - in 3.2: [wW]antBack -> [wW]antBacks, IsCA -> isCA,[TF]  already
fixed
*    SignResponse -> signResponse[TF]  already fixed
*    missing "," after queryExtensions and producedAt (same in 8)[TF]
already fixed
*  - in 3.2.3, including the title, [wW]antBack -> [wW]antBacks[TF]
wantBack is in the singular in the ASN?
*  - put 3.2.12 before 3.2.4 (to follow the field order) [TF] fixed
*  - in 3.2.12.2 KeyPurposedId -> keyPurposedId (in definition and
text),
*    ValidationNames -> validationNames [TF] fixed
*  - in 3.2.16 riType -> reType, riValue -> reValue [TF] fixed
*  - in 3.3 and 4.6 title Requestor -> requestor [TF] Already fixed
*  - in 4 id-ct-scvp-psResponse -> id-ct-scvp-certValResponse
(twice)[TF] Already fixed
*  - in 4 and 8, missing "," after validationPolRef [TF] Already fixed
*  - in 4.5.2 text PSRequest -> CVRequest [TF] Fixed
*  - in 4.8.5, including the title, [rR]eplyWantBack ->
[rR]eplyWantBacks [TF] fixed
*    (note this is *not* a suggestion, cf 4.8 where are the plurals
*     and there is a ReplyWantBack type too: caution!)
*  - in 4.11 IsCA -> isCA [TF] Fixed
*  - in 4.11 and 8 trustAnchors should be OPTIONAL (because in the
second
* usage, {TF] Fixed
*    PolResponse, there already is a trustAnchors field).
*  - in 6 and in 6.2, including title, DefaultPolicyID ->
defaultPolicyID
*  - in 6.7 AuthPolRefBy{OID,URI} -> authPolRefBy{OID,URI}
*  - in 8 (extra typos): [TF] Fixed
*    * Query: valalidationAlg -> validationAlg [TF] Fixed
*             keyusage -> keyUsage [TF] Fixed
*  - in B application/scvp-{request,response} ->
*         application/cv-{request,response} Fixed
* 
* Regards
* 
* [email-masked]

Content-class: urn:content-classes:message
Subject: RE: SCVP: Speak now or forever hold your peace... 
Date: Fri, 13 Aug 2004 17:23:06 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Francis Dupont" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Francis Dupont
* Sent: Wednesday, August 11, 2004 3:16 AM
* To: [email-masked]
* Cc: [email-masked]
* Subject: Re: SCVP: Speak now or forever hold your peace...
* 
* 
* Here are the ASN.1 bugs:
*  - CertReference is an ambiguous CHOICE. In a previous version
*    one tried to solve the ambiguity by changing the ACReference tags
*    to 3 and 4 (I don't know if this is really allowed or recognized
*    by compilers, of course it works but as I'd like to get the
reference
*    stuff a bit extended perhaps it is better to tag the CertReference
* itself).[TF]  Already fixed
*  - responseStatus 50 is missing in 4.4[TF]  fixed
*  - change the fullPolRequestUnsuported into fullPolResponseUnsuported
in
* 4.4[TF] fixed
*    and 8
*  - the cert field in CertReply is CertReference in 4.8 and
* ReplyCertificate
*    in 8. I prefer the 8 (and previous draft) version because it is a
*    simple way to enforce the return of the whole certificate. There
are
*    many ways to fix this:
*    - just fix 8
*    - same but add a want back to get the certificate itself (note that
* with
*      IKE the certificate itself is useful only if the name validation
*      algorithm doesn't work, and in the other case the public key is
*      enough).[TF]  Fixed
*    - just fix 8 and adding in 4.8.1 that the whole certificate is
* mandatory
*    - go back to previous draft, i.e., fix 4.8 and 4.8.1
*    (note: I prefer the second solution (and get the validation
algorithm
*     error issue fixed!))
*  - change the valAlg of CertReply (4.8 and 8) into validationAlg[TF]
[TF]  fixed
*  - fix the name of Pol{icies}Response in 5[TF]  fixed
*  - add the i to validationPolices (to get validationPolicies) in 6 and
*    add a subsection describing it between 6.5 and 6.6[TF]  fixed
* 
* Regards
* 
* [email-masked]
[TF] 
Trevor

Date: Fri, 13 Aug 2004 16:38:48 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Technical comments on SCVP Draft 15
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
All,<br>
<br>
Tim Polk asked me to review SCVP draft 15 in the hope of obtaining the
perspective of someone who has not read RFC 3379 nor any of the
preceding SCVP drafts.&nbsp; So, I read through draft 15 and prepared a set
of technical and editorial comments.&nbsp; The technical comments are
below.&nbsp; I will send the editorial comments directly to the editors.<br>
<br>
Dave<br>
<hr width="100%" size="2">
<title>Technical Comments on draft-ietf-pkix-scvp-15</title>
<meta content="OpenOffice.org 1.1.2  (Linux)" name="GENERATOR">
<meta content="David Cooper" name="AUTHOR">
<meta content="20040813;15350000" name="CREATED">
<meta content="David Cooper" name="CHANGEDBY">
<meta content="20040813;16192200" name="CHANGED">
<style>
	<!--
		@page { size: 8.27in 11.69in; margin: 0.79in }
		P { margin-bottom: 0.08in }
	-->
	</style>
<p style="margin-bottom: 0in;"><font size="3">Technical comments on
draft-ietf-pkix-scvp-15.txt:</font><br>
</p>
<ol>
  <li>
    <p><font size="3">General Comment: The document needs to clarify
the differences/relationships between validationAlg (3.2.12) and
validationPolRef (3.2.21) in the request and valPolResponse (4.11) and
validationPolRef (4.? - no section).</font></p>
  </li>
</ol>
<blockquote>
  <ul>
    <li>
      <p><font size="3">Assuming that the
ValidationPolRef can be a single reference specifying all the
contents of ValidationPolicy, then it is a superset of validationAlg.
Why is validationAlgorithm mandatory in the request? If you specify
a ValidationPolRef you wouldn't seem to need it.</font></p>
    </li>
    <li>
      <p><font size="3">When are valPolResponse
and validationPolRef included in a response? Could both appear?</font></p>
    </li>
    <li>
      <p><font size="3">If the server includes
valPolResponse, the validationAlgorithm is a mandatory field. If the
server includes certReply, valAlg is a mandatory field for every
cert. What if they conflict?</font></p>
    </li>
  </ul>
</blockquote>
<ol start="2">
  <li>
    <p><font size="3">Section 3: In the ASN.1, there are comments
indicating that SignedAttributes and AuthAttributes are required in the
SignerInfo and AuthenticatedData structures, respectively. What
attributes are required?</font></p>
  </li>
  <li>
    <p><font size="3">The new syntax for CertReference (below) makes it
difficult to distinguish between a public key certificate and an
attribute certificate. When the ESSCertID method is chosen, it will not
be possible to determine whether a public key or attribute certificate
has been referenced until the certificate has been obtained and parsed.
Even if the certificate is included, it will have to be at least
partially parsed before it can be determined what type of certificate
it is. Why were the tags in ACReference changed from [3] and [4] to [1]
and [2]?</font></p>
  </li>
</ol>
<blockquote>
  <blockquote><font size="3" face="Courier New">CertReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">pkc PKCReference,</font><font
 face="Courier New">
    <br>
    </font><font size="3" face="Courier New">ac ACReference }</font><font
 face="Courier New">
    <br>
    <br>
    </font><font size="3" face="Courier New">PKCReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">cert [1] Certificate,</font><font
 face="Courier New">
    <br>
    </font><font size="3" face="Courier New">pkcRef [2] ESSCertID }</font><font
 face="Courier New">
    <br>
    <br>
    </font><font size="3" face="Courier New">ACReference
::= CHOICE {</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">attrCert [1]
AttributeCertificate,</font><font face="Courier New">
    <br>
    </font><font size="3" face="Courier New">acRef [2] ESSCertID }</font><br>
  </blockquote>
</blockquote>
<ol start="4">
  <li>
    <p><font size="3">Sections 3.2.1, 3.2.2, and 3.2.3: Can the
queriedCerts item in a single request include both public key and
attribute certificates? There is nothing in section 3.2.1 that suggests
otherwise. However, in sections 3.2.2 and 3.2.2, each of the checks and
want backs defined is specific to either a public key certificate or an
attribute certificate. If the server must respond to each check and
want back for each certificate in the queriedCerts item, this would
suggest that a single query can not include both types of certificates.
An alternative would be for the server's response for each certificate
to only include responses to those checks and want backs that are
relevant to for the given type of certificate, however the
specification does not indicate that this is acceptable.</font></p>
  </li>
  <li>
    <p><font size="3">Section 3.2.9 states &#8220;If the client does not care
it MUST omit the Boolean.&#8221; However, the isCA flag is not OPTIONAL. isCA
may be either TRUE or FALSE, but may not be omitted.</font></p>
  </li>
  <li>
    <p><font size="3">Sections 3.2.6 through 3.2.8: Should
inhibitPolMap, requireExplicitPol, ignoreAnyPol also be OPTIONAL?
Otherwise, how can we indicate that we use the server&#8217;s default or
specify these values using the validationAlg or validationPolRef? </font>
    </p>
  </li>
  <li>
    <p><font size="3">Section 3.2.9:</font></p>
    <ul>
      <li>
        <p><font size="3">What is the purpose of the isCA flag?</font></p>
      </li>
      <li>
        <p><font size="3">Under what circumstances would the client
need to know whether the referenced certificate is a CA? Isn't it
sufficient to check that the certificate has the appropriate key usage,
extended key usage, policy, etc.? (NOTE: The cA field of the
basicConstraints extension indicates &#8220;if the certified public key may
be used to verify certificate signatures.&#8221; So, if the cA flag is TRUE,
then the certificate subject is a CA. However, a cA flag set to FALSE
or an absent basicConstraints extension does not mean that the
certificate subject is not a CA. It merely indicates that the subject
public key <u>in this certificate</u> may not be used to verify
certificate signatures.)</font></p>
      </li>
      <li>
        <p><font size="3">How should the isCA flag be set (and/or
interpreted) if the referenced certificate is an attribute certificate?</font></p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.12.2:</font></p>
    <ul>
      <li>
        <p><font size="3">This section is not clear. If the name
validation algorithm is specified, is the server expected to validate
the certificate according to the rules specified for the default
validation algorithm in addition to comparing the names? </font> </p>
      </li>
      <li>
        <p><font size="3">Why is name comparison a considered to be a
validation algorithm? Why isn't this treated the same way are keyUsage
or extendedKeyUsage?</font></p>
      </li>
      <li>
        <p><font size="3">What is the reason for the KeyPurposeID?
Aren't the name matching rules for DNs, email addresses, DNS names,
etc. the same no matter what protocol is being used?</font></p>
      </li>
      <li>
        <p><font size="3">If an email address is supplied, is the
server required to look in both the subjectAltName extension for the
subject field (in an emailAddress attribute) for the email address.</font></p>
      </li>
      <li>
        <p><font size="3">Where the text states &#8220;all names MUST be ...
valid according to the name matching rules requested.&#8221; Does this mean
that all of the names must appear in the certificate (i.e., that each
name in the request must match a name in the certificate, when the
specified name comparison rules are used).</font></p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.14 states:</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><tt><font size="3">The
OPTIONAL certPolicies item specifies a list of policy identifiers
that the SCVP server MUST use when forming and validating a
certification path that terminates at the associated trust anchor. If
certPolicies is not specified, then any-policy MUST be used.</font></tt></p>
<p style="margin-left: 0.49in;"><font size="3">Is there an implicit
assumption here that requireExplicitPol will be set to TRUE if
certPolicies is included?</font></p>
<ol start="10">
  <li>
    <p><font size="3">Section 3.2.15: The intermediateCerts is of type
CertBundle. Shouldn&#8217;t CertBundle be defined as <font
 face="Courier New, monospace">SEQUENCE SIZE (1..MAX) OF Certificate</font>
instead <font face="Courier New, monospace">SEQUENCE SIZE (1..MAX) OF
PKCReference</font>? If a server rec&#8217;d the ESSCertID choice of
PKCReference for the intermediateCerts, this implies the server would
already have the certificates. In this case, we didn&#8217;t need this field!</font></p>
  </li>
  <li>
    <p><font size="3">Section 3.2.17: Note we assume this applies only
to the end certificate. Even with this clarification, this section
needs to provide more information on how the match is performed.
Specifically:</font></p>
    <ul>
      <li>
        <p><font size="3">If more than one bit is set by the client, do
all of these bits need to be set in the key usage extension in the
certificate?</font></p>
      </li>
      <li>
        <p><font size="3">What if there is no key usage extension in
the certificate? Does this constitute an automatic match?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.18: Basically the same questions and
assumptions as for key usage:</font></p>
    <ul>
      <li>
        <p><font size="3">If the request includes more than one OID,
must all OIDs be present in the certificate?</font></p>
      </li>
      <li>
        <p><font size="3">What if there is no extended key usage
extension in the certificate? Does this constitute an automatic match?</font></p>
      </li>
      <li>
        <p><font size="3">If the extended key usage extension is
present and includes the anyExtendedKeyUsage OID, does this constitute
an automatic match or do the OIDs in the request need to be explicitly
asserted in the extension?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 3.2.21:</font></p>
    <ul>
      <li>
        <p><font size="3">Why is there a mandate to do a binary
comparison between policy references? If two URIs match according to
the standard matching rules for that type of URI (e.g., case
insensitive match), why wouldn't that be acceptable?</font></p>
      </li>
      <li>
        <p><font size="3">Does the URI <i>represent</i> a human
readable definition of the policy or does it <i>point</i> to a human
readable definition?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 4: Don't these two sentences contradict
each other?</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
inclusion of policies in the SigningCertificate attribute is also
OPTIONAL. The policies item in the SigningCertificate attribute SHALL
not be present.</font></font><br>
</p>
<ol start="15">
  <li>
    <p><font size="3">Section 4: I don't understand what the sentence
below means. More explanation is needed.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
value of the message-digest attribute in the signedAttrs within
SignerInfo MAY be used as an identifier of the response generated by
the SCVP server.</font></font></p>
<ol start="16">
  <li>
    <p><font size="3">Section 4: The statement below contradicts
section 3.4.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
requestNonce item MUST be included if the request included a
requestNonce item.</font></font></p>
<ol start="17">
  <li>
    <p><font size="3">Section 4.1 needs more explanation.</font></p>
    <ul>
      <li>
        <p><font size="3">Is the <font face="Courier New, monospace">svcpVersion</font>
number in the response required to match the <font
 face="Courier New, monospace">scvpVersion</font> number in the request
(if the server can process that version of SCVP)?</font></p>
      </li>
      <li>
        <p><font size="3">If the <font face="Courier New, monospace">svcpVersion</font>
number in the request is higher than the highest version number that
the server can process, is the server required to send an error
response? Should the <font face="Courier New, monospace">svcpVersion</font>
number in the response be the highest version number that the server
can process?</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 4.4: This sentence needs to be re-written
since there is no requirement to sign DPD responses if the <font
 face="Courier New, monospace">SignResponse</font> flag in the request
is FALSE.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">Status
codes 0-9 are reserved for codes where the request was processed by
the server and therefore MUST be sent in a signed response.</font></font></p>
<ol start="19">
  <li>
    <p><font size="3">Section 4.7: What is the reason for the responder
item? How is it used? It is included in the response but of only of
local significance? Perhaps this for retrospective audit trail lookups?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.1: Does the contents of the <font
 face="Courier New, monospace">cert</font> item in the response need to
match the contents of the corresponding certificate from the <font
 face="Courier New, monospace">queriedCerts</font> item in the request?
This is, if the request includes a <font face="Courier New, monospace">Certificate</font>,
does the response also need to include a <font
 face="Courier New, monospace">Certificate</font> rather than an <font
 face="Courier New, monospace">ESSCertID</font>? If the request
includes an <font face="Courier New, monospace">ESSCertID</font>, does
the response need to include an <font face="Courier New, monospace">ESSCertID</font>
rather than a <font face="Courier New, monospace">Certificate</font>?</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
cert item contains either the public key certificate or the attribute
certificate or a reference to the certificate about which the client
is requesting information.</font></font></p>
<ol start="21">
  <li>
    <p><font size="3">Section 4.8.2: Why aren't the errors below <font
 face="Courier New, monospace">responseStatus</font> errors? Since each
of these applies to every certificate, making it a <font
 face="Courier New, monospace">replyStatus</font> means repeating the
same error for every certificate in the query rather than just
specifiying the error once.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">5 Failure: the
certificate policy OID is not recognized</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">6 Failure: the validation
<strike><font color="#0000ff">policy</font></strike>
<u><font color="#0000ff">algorithm</font></u> OID is not recognized</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">7 Failure: the extension
OID is not recognized</font></font></p>
<ol start="22">
  <li>
    <p><font size="3">Section 4.8.2: The conditions that would lead to
one of the error values below should really result in a <font
 face="Courier New, monospace">ReplyStatus</font> of <font
 face="Courier New, monospace">success</font> (0) since &#8220;a definitive
answer follows&#8221;. The definitive answer that follows will be that no
valid path could be constructed (e.g., in <font
 face="Courier New, monospace">ReplyChecks</font> and/or <font
 face="Courier New, monospace">replyWantBacks</font>).</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">10
Failure: no certification path could be constructed</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">11
Failure: the constructed certification path is invalid</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">12
Failure: the constructed certification path is invalid, but a
query at a later time may be successful</font></font></p>
<ol start="23">
  <li>
    <p><font size="3">Section 4.8.4: In responses to <font
 face="Courier New, monospace">{id-stc 3}</font>, <font
 face="Courier New, monospace">{id-stc 6}</font>, and <font
 face="Courier New, monospace">{id-stc 7}</font>, what is the
difference between Unknown (2) and Unavailable (3)?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.4 and 4.8.5: The reply check {id-stc
1} (simple validation processing with no status checking) or {id-stc 2}
(but with the Revoked, Unknown, and Unavailable responses being
condensed down to FALSE) would seem to correspond to the wantback for
public key certificate status, { id-swb 3 }.</font></p>
  </li>
</ol>
<blockquote>
  <p style="margin-left: 0.21in;"><font size="3">We should eliminate
the
wantback (or clarify the difference!)</font></p>
</blockquote>
<ol start="25">
  <li>
    <p><font size="3">Section 4.8.5: Same question as above. How does
wantback { id-swb 8 } differ from the corresponding check item { id-stc
7 }? Why is it needed?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.6: Is valAlg required to match the
validationAlg specified in the request or can the server choose a
different validation algorithm?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.8.7: Should the <font
 face="Courier New, monospace">nextUpdate</font> item be included if
the validation time is not the current time?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.11: More information needs to be
provided about what information can be implicitly specified by a <font
 face="Courier New, monospace">ValidationPolRef</font>. This section
seems to indicate that things such as the value for <font
 face="Courier New, monospace">inhibitPolMap</font> can be part part of
the definition of a policy reference. However, section 3.2.21 states
that a server must return an error if there a a discrepency between the
policy reference and the contents of the request and <font
 face="Courier New, monospace">inhibitPolMap</font> is not an optional
item in the request. So, if the value for <font
 face="Courier New, monospace">inhibitPolMap</font> is specified in the
policy referrence, the client will be forced to specify the same value
for this boolean in its request in order to avoid an error response,
making its inclusion as part of the definition of the policy reference
useless. Is a <font face="Courier New, monospace">ValidationPolRef</font>
limited to defining values for the parameters specified in <font
 face="Courier New, monospace">ValPolicy</font> in section 4.11?</font></p>
  </li>
  <li>
    <p><font size="3">Section 4.13.1: paragraph 1 sentences 2 through 4
are confusing.</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">It
is a<u><font color="#0000ff">n</font></u> implementation decision how
the keys are stored. This can be accomplished by cryptographic hashes
of public keys used to sign signedData responses. It could also be
shared symmetric keys used to HMAC authenticatedData responses.</font></font></p>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font size="3">Could
we replace these three sentences with: &nbsp; </font><font
 face="Courier New, monospace"><font size="3">Mechanisms for storage
of server keys or identifiers is a local matter. For example, a
client could store cryptographic hashes of public keys used to verify
signedData responses. Alternatively, a client could store shared
symmetric keys used to HMAC authenticatedData responses.</font></font></p>
<ol start="30">
  <li>
    <p><font size="3">Section 5: What is the meaning of the <font
 face="Courier New, monospace">svcpVersion</font> in the request? Is it
the highest version number that the client supports?</font></p>
  </li>
  <li>
    <p><font size="3">Section 6.1: Does the <font
 face="Courier New, monospace">svcpVersion</font> number in the
response need to match the <font face="Courier New, monospace">svcpVersion</font>
number in the request? If the highest version that the server can
process is lower than the version specified by the client, should it
specify the highest version number that it can process? If the version
specified by the client is lower than the highest version number that
the server can process, is the server required to respond with a
version number equal to that in the request?</font></p>
  </li>
  <li>
    <p><font size="3">Section 6:</font></p>
    <ul>
      <li>
        <p><font size="3">Is <font face="Courier New, monospace">validationPolicies</font>
the set of <font face="Courier New, monospace">ValidationPolRef</font>
that the server supports, whereas <font face="Courier New, monospace">defaultValPol</font>
is the validation policy used if none is specified? The <font
 face="Courier New, monospace">validationPolices</font> item is not
defined in this section.</font></p>
      </li>
      <li>
        <p><font size="3">What is <font face="Courier New, monospace">authDataCert</font>?
It is not defined.</font><br>
        </p>
      </li>
    </ul>
  </li>
  <li>
    <p><font size="3">Section 9: Section 6 states that the policies
response MUST be signed. This conflicts with the seventh paragraph in
the Security Considerations:</font></p>
  </li>
</ol>
<p style="margin-left: 0.49in; margin-bottom: 0in;"><font
 face="Courier New, monospace"><font size="3">The
request and response for which policies are supported on the server
are unsigned. These could lead to a denial of service attack where a
man-in-the-middle indicates that a server supports a different set of
validation policies than it actually does. This could result in the
client requesting validation based on a policy the server does not
support or lead the client using a less desirable policy.</font></font></p>
<blockquote>
  <p style="margin-left: 0.21in; margin-bottom: 0in;"><font size="3">Perhaps
we can delete this text from security considerations?</font></p>
</blockquote>
<br>
<br>
</body>
</html>

Date: Fri, 13 Aug 2004 15:22:08 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP issue
Cc: <[email-masked]>
Sender: [email-masked]

At 11:50 AM -0700 8/13/04, Trevor Freeman wrote:
>Hi Steve,
>I find this posting puzzling. As our private exchange established, the
>only mandated field a SCVP client is required to support is the
>validation policy reference. Therefore simple clients which only supply
>a policy references are conformant to the standard. All other fields are
>optional.  True I don't consider a policy reference has to be via an
>OID. There are other way to unambiguously refer to a set of rules which
>do not burden deployments and are successfully used for the same
>function in other standards to there is no precedence that the policy
>reference MUST be an OID. SCVP support the use of OIDS but does not
>mandate there use since that is ultimately a deployment decision.

You start by saying that you don't see why I'm bringing this up on 
this list, but the paragraph above makes it clear that we have very 
different views of what should be mandated support vs. optional 
support.  I've discussed my rationale for why I think OIDs should be 
a MUST, and parameters ought to be a SHOULD or MAY, but our exchanges 
have made no progress. Others in the off list discussion have 
expressed similar concerns. The reason for bringing this to the list 
is simple: if the WG shows a clear preference one way or the other, 
we can make sure the next rev of SCVP represents WG consensus.

>One the subject of parameters there is a big difference between optional
>standard parameters which are common to all polices e.g. root
>certificates, and completely new parameters. A validation policy is not
>mandated to cover all standard parameters e.g. it may only define the
>root certificates and 3379 mandates that the protocol be capable of
>passing other parameters. SCVP defiles how to pass all the standard
>parameters associated with the default validation algorithm. Other
>non-standard parameters are defined via the validation algorithm OID.

I don't disagree with your characterization above, but it fails to 
counter the argument I cited for why mandatory support for OIDs 
provides a more general and simpler way to ensure compatibility 
between different client and server implementations.

>There are also numerous cases where the corporate wide policy does not
>work for all departments or subsidiaries and those departments
>/subsidiaries have there own polices. Why cannot a department or
>subsidiary have simple devices, have their own policy and simply use the
>central server as a resource e.g. the department or subsidiary trusts
>the corporate servers to validate requests under a policy that they
>define. The state management software for the simple device can handle
>multiple parameters. It has to handle at least 3 (server URL, server key
>and policy reference) and it is not stressed by a couple more.

Your argument here assumes a corporate-wide server, which may or may 
not be true. It also assumes an inability for departments to cause 
additional policies to be configured in a corporate server, but an 
ability to correctly manage per-client parameters in all the clients 
for each department that does not follow a monolithic policy. Yes, 
all of these are possible situations, but there are a lot of "ifs" 
here. Also, its not just a matter of the software in the clients 
being able to "handle" the added parameters, but rather the ability 
of folks to correctly manage them.

I notice that you didn't repeat the last argument from our off-list 
discussion, here. There you argued that the decision of which way to 
represent policy (OID vs. list of parameters) was best left to the 
implementers of applications for the clients, vs. local IT managers. 
The argument does not seem to be consistent with the argument above, 
where the issue is one of local IT managers vs. corporate IT 
managers. Since you made the IT manager vs. implementer argument 
before, I though it would be good to mention it here for completeness.

Steve

Steve

Content-class: urn:content-classes:message
Subject: RE: SCVP issue
Date: Fri, 13 Aug 2004 11:50:42 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Steve,
I find this posting puzzling. As our private exchange established, the
only mandated field a SCVP client is required to support is the
validation policy reference. Therefore simple clients which only supply
a policy references are conformant to the standard. All other fields are
optional.  True I don't consider a policy reference has to be via an
OID. There are other way to unambiguously refer to a set of rules which
do not burden deployments and are successfully used for the same
function in other standards to there is no precedence that the policy
reference MUST be an OID. SCVP support the use of OIDS but does not
mandate there use since that is ultimately a deployment decision.

One the subject of parameters there is a big difference between optional
standard parameters which are common to all polices e.g. root
certificates, and completely new parameters. A validation policy is not
mandated to cover all standard parameters e.g. it may only define the
root certificates and 3379 mandates that the protocol be capable of
passing other parameters. SCVP defiles how to pass all the standard
parameters associated with the default validation algorithm. Other
non-standard parameters are defined via the validation algorithm OID. 

There are also numerous cases where the corporate wide policy does not
work for all departments or subsidiaries and those departments
/subsidiaries have there own polices. Why cannot a department or
subsidiary have simple devices, have their own policy and simply use the
central server as a resource e.g. the department or subsidiary trusts
the corporate servers to validate requests under a policy that they
define. The state management software for the simple device can handle
multiple parameters. It has to handle at least 3 (server URL, server key
and policy reference) and it is not stressed by a couple more.

Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Stephen Kent
* Sent: Friday, August 13, 2004 8:01 AM
* To: [email-masked]
* Subject: SCVP issue
* 
* 
* Folks,
* 
* A few of us have been discussing (off list) the issue of having a
* client send an OID to specify a validation policy at an SCVP (DPV)
* server, vs. having the client send parameters to direct validation.
* 
* My position is that support for OID-based policy references should be
* the default, and the mandatory minimum policy specification mechanism
* for both clients and servers, i.e., a MUST, and that support for
* explicit parameter passing should be an option, a SHOULD or MAY.
* there are several reasons for
* my saying this.
* 
* First, configuring a client to pass an OID is obviously simpler than
* configuring the client with all the parameters needed to direct path
* validation, and with the default policy feature that SCVP must
* support, one could image a zero-config  situation in some contexts.
* In general enterprises find it hard to manage configuration info for
* every client, and this problem is only magnified as the number of
* configuration parameters grows. Thus OID-specified validation is much
* simpler than parameter-specified validation, from a client
* perspective. Since the "S" in SCVP does stand for simple, ...
* 
* Also, as Trevor brought to my attention, one may choose to define
* additional
* parameters that define cert validity for a given application context,
* beyond the standard set of parameters used for path validation. If we
* want a allow an administrator to define such validation policies, we
* can't assume that standard clients will be prepared to convey the
* necessary parameters. This is especially
* true if we assume that the clients and servers are not produced by
* the same vendor. So, only via use of OIDs can we hope to allow such
* customization of cert validity in mixed vendor (or mixed version)
* environments.
* 
* These two points seem to argue for making OIDs the MUST method for
* conveying cert validation selection between  client and server,
* relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
* 
* I'd like to receive feedback fro the list on this issue.
* 
* Steve

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: SCVP issue
Date: Sat, 14 Aug 2004 01:33:23 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

My position is that since SCVP is supposed to be a "simple"
protocol, it sould in default provide better support to simple clients.

I do not object to provide the possibility to allow a "complex"
client to send a full set of parameters to a "complex"
server. However, this can be done via an EXTENSION
mechanism. I strongly suggest that we should remove
all parameter fields from the current syntax and instead add
an EXTENSION mechanism to the SCVP Query
structure or the Validation Policy reference structure.
And then, we can define some standard EXTENSIONs
to allow a "complex" client to send RFC 3280 parameters,
revocation info requirements, or additional conditions (such
as name matching rules, key usage requirements, etc.)
to a  "complex" server that understand these extensions.
This way, we will keep the basic syntax of SCVP as simple
as possible but preserve the extensibility of the protocol.

=====
Wen-Cheng Wang

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 13, 2004 11:01 PM
Subject: SCVP issue

>
> Folks,
>
> A few of us have been discussing (off list) the issue of having a
> client send an OID to specify a validation policy at an SCVP (DPV)
> server, vs. having the client send parameters to direct validation.
>
> My position is that support for OID-based policy references should be
> the default, and the mandatory minimum policy specification mechanism
> for both clients and servers, i.e., a MUST, and that support for
> explicit parameter passing should be an option, a SHOULD or MAY.
> there are several reasons for
> my saying this.
>
> First, configuring a client to pass an OID is obviously simpler than
> configuring the client with all the parameters needed to direct path
> validation, and with the default policy feature that SCVP must
> support, one could image a zero-config  situation in some contexts.
> In general enterprises find it hard to manage configuration info for
> every client, and this problem is only magnified as the number of
> configuration parameters grows. Thus OID-specified validation is much
> simpler than parameter-specified validation, from a client
> perspective. Since the "S" in SCVP does stand for simple, ...
>
> Also, as Trevor brought to my attention, one may choose to define
additional
> parameters that define cert validity for a given application context,
> beyond the standard set of parameters used for path validation. If we
> want a allow an administrator to define such validation policies, we
> can't assume that standard clients will be prepared to convey the
> necessary parameters. This is especially
> true if we assume that the clients and servers are not produced by
> the same vendor. So, only via use of OIDs can we hope to allow such
> customization of cert validity in mixed vendor (or mixed version)
> environments.
>
> These two points seem to argue for making OIDs the MUST method for
> conveying cert validation selection between  client and server,
> relegating parameter passing to a lesser status, e.g., SHOULD or MAY.
>
> I'd like to receive feedback fro the list on this issue.
>
> Steve
>

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Fri, 13 Aug 2004 10:14:52 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
The validation algorithm in 3280 section 6 works for all certificates.
Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 4:30 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > *
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* 
* 
* It seems that SCVP pretends to be able to valdidate *ANY* CA
certificate
* by using the isCA boolean which I think cannot work.
* 
* First, we are clearly outside the scope of the
* algorithm inputs of path validation algorithm of 3280, since the
* algorithm works is intended to work for EEs:
* 
*    The primary goal of path validation is to verify the binding
between
*    a subject distinguished name or a subject alternative name and
*    subject public key, as represented in the end entity certificate,
* 
* The algorithm still can work slightly modified if the EE cert is not
* present, in order just to validate the first CA.
* 
* But, in order to validate an intermediate CA that has not signed
directly
* the EE cert, one has to assume that the client has performed the 3280
* validation
* up to the CA in question, and one has to give correct information to
the
* SCVP
* server to do "the rest" or you have to return the intermediate values,
* i.e. the current maximum path length still allowed.
* 
* Assume you want a valid path for CA2 signing CA1 and an EE cert
* and you have a situation like
* 
*   EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
*                    <- CA3withpathlength1 <- CAY .. othetrustanchor.
* 
* you cannot avoid that the SCVP server returns the first path
* which would not be valid to sign EE with an intermediate CA1.
* 
* 
* 
* 
* 
* 

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Fri, 13 Aug 2004 10:12:32 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
The question in point still comes back to how was the certificate
validated i.e. the algorithm and the parameters used by the server when
it returned the positive response. SCVP defines a default algorithm
where the server performs the path validation itself and provides an
extension mechanisms to define other algorithms. I don't see any
blocking issues to you defining a new validation algorithm which
encompasses DPV server delegating the validation decision to other DPV
server.
Trevor 

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Friday, August 13, 2004 2:49 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > Hi Peter,
* > I don't see any clause in 3379 that requires SCVP to support the
* > scenario you describe. In fact section 4.2 states "Protocols
designed to
* > satisfy these requirements MAY include optional fields and/or
extensions
* > to support relaying, re-direction or multicasting."
* 
* SCVP explicitely supports relaying.
* 
* The description of relaying in SCVP implies that the relaying
* server obtains a response from a remote server, and has to interprete
* it to provide a positive response, since the initial client does
* not necessarily trust the remote server.
* 
* > Therefore SCVP meets the 3379 requirements. The scenario you
describe
* > requires at a minimum the rely server to have a new validation
algorithm
* > because as you describe  it is not verifying the result itself but
* > verifying the DPV response from another server. Therefore you are at
* > liberty to define such extensions.
* 
* There is no need for any extension.
* 
* The relaying server creates a valid path and indicates *ALL*
information
* that it has used to determine this information. And since SCVP allows
* for relaying, it must alow allow for returning the response from the
* remote server as is, quite similar as for OCSP reponses etc.
* 
* 
* 
* 

Date: Fri, 13 Aug 2004 12:45:57 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SCVP issue
Cc: [email-masked]
Sender: [email-masked]

At 5:51 PM +0200 8/13/04, Peter Sylvester wrote:
>  >>
>>  I'd like to receive feedback fro the list on this issue.
>
>Does the following corresponds in some way to your idea?
>
>
>>From sylvest Thu May  6 18:25:04 2004
>To: [email-masked], [email-masked]
>Subject: Re: FW: scvp
>Cc: [email-masked]
>
>I agree with Denis about a single value policy.
>
>I think that we have already a structure elsewhere that
>is close to what can be used. 
>
>    PolicyInformation ::= SEQUENCE {
>         policyIdentifier   CertPolicyId,
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
>
>    CertPolicyId ::= OBJECT IDENTIFIER
>
>    PolicyQualifierInfo ::= SEQUENCE {
>         policyQualifierId  PolicyQualifierId,
>         qualifier          ANY DEFINED BY policyQualifierId }
>
>
>the PolicyQualifierId would be an indidation of a
>particular algorithm that needs to be performed and its
>parameters. one would be "3280 path processing input"
>another would be 'end entry naming comparison', etc.

this seems like a reasonable way to encode this info. I don't have 
strong opinions re the encoding choice. First I'd like to get 
agreement on the OIDs vs. parameters question.

Steve

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on SCVP Draft 15
Date: Sat, 14 Aug 2004 00:59:12 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Sorry! I forgot one comment in my last post.

11. Section 3.2.12.2
It is strange to have "Name Validation Algorithm" as a sub section of
of "3.2.12 validationAlg". Does it means a "Name Validation Algorithm"
itself can be regarded as a certificate validation algorithm?
My understanding is a Name Validation Algorithm is only a part of the
whole validation algorithm (or is an additional conditions to the validation
algorithm, it can not be used to replace the whole validation algorithm.
However, with the current syntax, if one specifies a Name Validation
Algorithm, then it can not specify the validation algorithm anymore. That
is unreasonable.

=====
Wen-Cheng Wang

----- Original Message ----- 
From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, August 14, 2004 12:45 AM
Subject: Comments on SCVP Draft 15

> Here is my comments on SCVP Draft 15:
>
> 1. Should it be called "certificate path" or "certification path"?
> In SCVP Draft 15, sometimes it is called "certificate path",
> otherwhile it is called "certification path"? Please be consistent.
> I believe that "certification path" is the mainstream use.
>
> 2. Do we really need to keep the validationAlg item in the SCVP Query?
> It is very confusing to have both the references of a validation policy
> and a validation algorithm in the SCVP Query. There is a large
> overlap between the concepts of a validation policy and a validation
> algorithm. My understanding is that the validation algorithm is part
> of the validation policy. That is, if one specifies a validation policy,
> then it already implies a validation algorithm. Therefore, there is
> no need to have a validationAlg item in the SCVP Query. If we
> remove a validationAlg item from the SCVP Query, we can still
> regard inputs such as trust anchors, user-initial-policy-set,
> initial-policy-mapping-inhibit, initial-explicit-policy, or
> initial-any-policy-inhibit as parameters to the validation policy.
> (Be sure to make all these parameters optional, because the
> validation might already implies all of them.)
>
> 3. Please consider to reorganize the SCVP Query data structure.
> Especially, please consider to group parameters such as trust anchors,
> user-initial-policy-set, initial-policy-mapping-inhibit,
> initial-explicit-policy,
> or initial-any-policy-inhibit into a sub-structure. (If I remember
> correctly,
> Denis had similar opinion.)
>
> In my opinion, the current syntax for the SCVP Query data structure is
> not only ugly but also very likely causes ambiguity. For example, it is
> not clear if one can specify any parameters without specifing a
> validation policy (or a validation algorithm). I believe that design
> good data structures is an important part of designing a protocol.
> A good protocol should have well-designed data structures. That
> is the principle of data structures we learnt in the college computer
> science
> course, isn't it?
>
> 4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
> IsCA should be OPTIONAL fields instead of being fields with a DEFAULT
> value. In many cases, the client would like to OMIT these parameters. (For
> example in the cases where the validation policy implies all the
> parameters.)
> If we let these parameters be  fields with a DEFAULT value, then there
> is no way to distinct whether the client want to omit them or want to
> use the default value. Besides, there is no consensus on the default value
> for these parameters in this WG. Especially, I do not agree why the
default
> value for requireExplicitPol is FALSE, because I believe most serious
> verifiers would require a explict certificate policy be set in all
> certificates
> in the path.
>
> 5. Please consider change the name of the parameters to align with
> the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
> a bad name. Please note that it is called 'initial-any-policy-inhibit'
> in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
> Besides, since all these parameters are all 'initial' parameters, I
> think it is better to keep the 'initial' in their names. Therefore, how
> about change their name into 'initPolMapInhibit', 'initExplicitPol',
> 'initAnyPolInhibit', and 'initCertPolSet'.
>
> 6. Section 3.2.4
> What if the client requests the server to include the full request in
> the response but the server does not support that? Should the
> server return a error to the client? If not, should the client reject the
> response that only includes a hash of the request?
>
> 7. Section 3.2.5
> What if the client requests the server to include the fullPolResponse
> in the CVResponse but the server does not support that? Should
> the server return a error to the client? If not, should the client reject
> the response that does not include the fullPolResponse in the
> CVResponse?
>
> 8. Section 3.2.10
> What if the client requests the server to sign the response but the
> server does not support that? Should the server return a error to
> the client? If not, should the client reject the unsigned response?
>
> 9. Section 3.2.13
> In additional to supporting validating a certificate relative to a
> specific validatyTime or current time, it is also important to allow
> the client to ask the server whether the target certificate
> is valid during a "time period" (i.e., from time t1 to time t2).
> In the cases where a client want to verify a long-term digital
> signature which might be signed between time t1 and time t2,
> the client needs make sure whether the signer's certificate
> is valid from time t1 to time t2. Please take a look at RFC 3126
> and the paper titled "General principles of digital signature"
> (http://www.timestamp.cyber.ee/principles_en.pdf), then you will
> see why it is important to determine whether the target certificate
> is valid during a "time period".
>
> 10. Section 3.2.14
> I do not see why user-initial-policy-set needs to be associated
> with the trust anchor. This is not align with RFC 3280. Please
> consider moving this parameter to the same level as other
> parameters such as initial-policy-mapping-inhibit,
> initial-explicit-policy, and initial-any-policy-inhibit.
>
> =====
> Wen-Cheng Wang
>

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Comments on SCVP Draft 15
Date: Sat, 14 Aug 2004 00:45:58 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Here is my comments on SCVP Draft 15:

1. Should it be called "certificate path" or "certification path"?
In SCVP Draft 15, sometimes it is called "certificate path",
otherwhile it is called "certification path"? Please be consistent.
I believe that "certification path" is the mainstream use.

2. Do we really need to keep the validationAlg item in the SCVP Query?
It is very confusing to have both the references of a validation policy
and a validation algorithm in the SCVP Query. There is a large
overlap between the concepts of a validation policy and a validation
algorithm. My understanding is that the validation algorithm is part
of the validation policy. That is, if one specifies a validation policy,
then it already implies a validation algorithm. Therefore, there is
no need to have a validationAlg item in the SCVP Query. If we
remove a validationAlg item from the SCVP Query, we can still
regard inputs such as trust anchors, user-initial-policy-set,
initial-policy-mapping-inhibit, initial-explicit-policy, or
initial-any-policy-inhibit as parameters to the validation policy.
(Be sure to make all these parameters optional, because the
validation might already implies all of them.)

3. Please consider to reorganize the SCVP Query data structure.
Especially, please consider to group parameters such as trust anchors,
user-initial-policy-set, initial-policy-mapping-inhibit,
initial-explicit-policy,
or initial-any-policy-inhibit into a sub-structure. (If I remember
correctly,
Denis had similar opinion.)

In my opinion, the current syntax for the SCVP Query data structure is
not only ugly but also very likely causes ambiguity. For example, it is
not clear if one can specify any parameters without specifing a
validation policy (or a validation algorithm). I believe that design
good data structures is an important part of designing a protocol.
A good protocol should have well-designed data structures. That
is the principle of data structures we learnt in the college computer
science
course, isn't it?

4. Parameters such as inhibitPolMap, requireExplicitPol, ignoreAnyPol,
IsCA should be OPTIONAL fields instead of being fields with a DEFAULT
value. In many cases, the client would like to OMIT these parameters. (For
example in the cases where the validation policy implies all the
parameters.)
If we let these parameters be  fields with a DEFAULT value, then there
is no way to distinct whether the client want to omit them or want to
use the default value. Besides, there is no consensus on the default value
for these parameters in this WG. Especially, I do not agree why the default
value for requireExplicitPol is FALSE, because I believe most serious
verifiers would require a explict certificate policy be set in all
certificates
in the path.

5. Please consider change the name of the parameters to align with
the names used in RFC 3280. Especially, I think 'ignoreAnyPol' is
a bad name. Please note that it is called 'initial-any-policy-inhibit'
in RFC 3280, and 'inhibit' and 'ignore' have quite different meaning.
Besides, since all these parameters are all 'initial' parameters, I
think it is better to keep the 'initial' in their names. Therefore, how
about change their name into 'initPolMapInhibit', 'initExplicitPol',
'initAnyPolInhibit', and 'initCertPolSet'.

6. Section 3.2.4
What if the client requests the server to include the full request in
the response but the server does not support that? Should the
server return a error to the client? If not, should the client reject the
response that only includes a hash of the request?

7. Section 3.2.5
What if the client requests the server to include the fullPolResponse
in the CVResponse but the server does not support that? Should
the server return a error to the client? If not, should the client reject
the response that does not include the fullPolResponse in the
CVResponse?

8. Section 3.2.10
What if the client requests the server to sign the response but the
server does not support that? Should the server return a error to
the client? If not, should the client reject the unsigned response?

9. Section 3.2.13
In additional to supporting validating a certificate relative to a
specific validatyTime or current time, it is also important to allow
the client to ask the server whether the target certificate
is valid during a "time period" (i.e., from time t1 to time t2).
In the cases where a client want to verify a long-term digital
signature which might be signed between time t1 and time t2,
the client needs make sure whether the signer's certificate
is valid from time t1 to time t2. Please take a look at RFC 3126
and the paper titled "General principles of digital signature"
(http://www.timestamp.cyber.ee/principles_en.pdf), then you will
see why it is important to determine whether the target certificate
is valid during a "time period".

10. Section 3.2.14
I do not see why user-initial-policy-set needs to be associated
with the trust anchor. This is not align with RFC 3280. Please
consider moving this parameter to the same level as other
parameters such as initial-policy-mapping-inhibit,
initial-explicit-policy, and initial-any-policy-inhibit.

=====
Wen-Cheng Wang

Date: Fri, 13 Aug 2004 18:12:42 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: SCVP issue
Sender: [email-masked]

Stephen Kent wrote:

> First, configuring a client to pass an OID is obviously simpler than 
> configuring the client with all the parameters needed to direct path 
> validation, [...]

In other words, OID enables server based configuration management, 
whereas the other has to be client based.

Seen like that, this is /etc/host against DNS, and there is no 
hesitation as to which one is the right choice.

Date: Fri, 13 Aug 2004 17:51:01 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SCVP issue
Sender: [email-masked]

>> 
> I'd like to receive feedback fro the list on this issue.

Does the following corresponds in some way to your idea?

Date: Fri, 13 Aug 2004 11:01:20 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: SCVP issue
Sender: [email-masked]

Folks,

A few of us have been discussing (off list) the issue of having a 
client send an OID to specify a validation policy at an SCVP (DPV) 
server, vs. having the client send parameters to direct validation.

My position is that support for OID-based policy references should be 
the default, and the mandatory minimum policy specification mechanism 
for both clients and servers, i.e., a MUST, and that support for 
explicit parameter passing should be an option, a SHOULD or MAY. 
there are several reasons for
my saying this.

First, configuring a client to pass an OID is obviously simpler than 
configuring the client with all the parameters needed to direct path 
validation, and with the default policy feature that SCVP must 
support, one could image a zero-config  situation in some contexts. 
In general enterprises find it hard to manage configuration info for 
every client, and this problem is only magnified as the number of 
configuration parameters grows. Thus OID-specified validation is much 
simpler than parameter-specified validation, from a client 
perspective. Since the "S" in SCVP does stand for simple, ...

Also, as Trevor brought to my attention, one may choose to define additional
parameters that define cert validity for a given application context, 
beyond the standard set of parameters used for path validation. If we 
want a allow an administrator to define such validation policies, we 
can't assume that standard clients will be prepared to convey the 
necessary parameters. This is especially
true if we assume that the clients and servers are not produced by 
the same vendor. So, only via use of OIDs can we hope to allow such 
customization of cert validity in mixed vendor (or mixed version) 
environments.

These two points seem to argue for making OIDs the MUST method for 
conveying cert validation selection between  client and server, 
relegating parameter passing to a lesser status, e.g., SHOULD or MAY.

I'd like to receive feedback fro the list on this issue.

Steve

Date: Fri, 13 Aug 2004 14:21:18 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: Speak now or forever hold your peace...
Sender: [email-masked]

3.3 Requestor 
   
  The requestor item MUST be an octet string.  

What is the reason for this statement. It is defined as an ASN1
octet string. So there is no other choice.

                                              No provisions are made 
  to ensure uniqueness of the requestor octet string; however, all of 
  the octets MUST have values other than zero.

This is inconsistent of what is specified in relaying
where zeros are allowed. 

7 SCVP Server Relay 

... 
 
  When an SVCP server receives a request that contains a requestor 
  item, the server MUST check for its own identifier.  The identifier 
  could be located at the beginning of the octet string followed by a 
  zero octet, or it could be located between two zero octets.

With thgis logic a server cannot detect immediately a loop to itself
of a request relayed to it by another server.

I strongly suggest again to replace this handling by using a sequence
of octet strings at least for the second request instaed of this
null logic.  

Date: Fri, 13 Aug 2004 14:11:56 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: Speak now or forever hold your peace...
Sender: [email-masked]

Paragraph 3.2.17 does not seem clear enough to me. It
does not indicate how the server performs the matching
between the provided keyusage bit string and the
bitstring in the candidate certificate. 

It should be clarified whetyher this is a conparison
for identity or whether it is tested that all 1 bits
in the client provided string are also 1 in the
cert. 

Isn't there a ',' missing behind 'Therefore'.

in a context of a digital signature, the nonrepudiation
bit alone can be used as far as I remember. 

How can one ask for either keyEncipherment or keyAgreement
in the case of a serverAuth or an email cert. 

Date: Fri, 13 Aug 2004 13:29:38 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> * 
> * To which value do you intialize max_path_length of point k in 6.1.2
> * if you want to validate a CA cert that is used to signed another CA?
> * 
> [TF] SCVP supports all the inputs as defined in 6.1.1

It seems that SCVP pretends to be able to valdidate *ANY* CA certificate
by using the isCA boolean which I think cannot work.

First, we are clearly outside the scope of the 
algorithm inputs of path validation algorithm of 3280, since the
algorithm works is intended to work for EEs:

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the end entity certificate,

The algorithm still can work slightly modified if the EE cert is not
present, in order just to validate the first CA. 

But, in order to validate an intermediate CA that has not signed directly
the EE cert, one has to assume that the client has performed the 3280 validation
up to the CA in question, and one has to give correct information to the SCVP
server to do "the rest" or you have to return the intermediate values, 
i.e. the current maximum path length still allowed. 

Assume you want a valid path for CA2 signing CA1 and an EE cert
and you have a situation like

  EE <- CA1 <- CA2 <- CA3withpathlength0 <- CAX .. sometrustanchor
                   <- CA3withpathlength1 <- CAY .. othetrustanchor.

you cannot avoid that the SCVP server returns the first path
which would not be valid to sign EE with an intermediate CA1.

Date: Fri, 13 Aug 2004 11:49:15 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi Peter,
> I don't see any clause in 3379 that requires SCVP to support the
> scenario you describe. In fact section 4.2 states "Protocols designed to
> satisfy these requirements MAY include optional fields and/or extensions
> to support relaying, re-direction or multicasting."

SCVP explicitely supports relaying.

The description of relaying in SCVP implies that the relaying
server obtains a response from a remote server, and has to interprete
it to provide a positive response, since the initial client does
not necessarily trust the remote server. 

> Therefore SCVP meets the 3379 requirements. The scenario you describe
> requires at a minimum the rely server to have a new validation algorithm
> because as you describe  it is not verifying the result itself but
> verifying the DPV response from another server. Therefore you are at
> liberty to define such extensions.

There is no need for any extension. 

The relaying server creates a valid path and indicates *ALL* information
that it has used to determine this information. And since SCVP allows
for relaying, it must alow allow for returning the response from the
remote server as is, quite similar as for OCSP reponses etc. 

Date: Fri, 13 Aug 2004 10:46:57 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace...
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Good news. 
I stand corrected.
Thanks for the information. 
Peter

> -----
> There are **MANY** ASN.1 specs that have tags in excess of 30.
> I know of no commercial-grade ASN.1 toolkit, nor any of the
> popular free ones, that suffers from such a deficiency.
> 
> In the early 1990's the implementor's organization in Europe, the U.S.A
> (NIST Stable Implementation Guideline) and Asia agreed that ASN.1 specs
> should not use tag numbers greater than 16383, and implicitly, that tools
> should support tags of at least that size.  To the best of my knowledge
> all commercial-grade and popular free ASN.1 toolkits support tags this
> large.
> -----
> 
> Olivier
> 

From: "Administrator" <[email-masked]>
To: [email-masked]
Subject: Staff Bulletin
Date: Fri, 13 Aug 04 07:20:46 GMT

This is a multi-part message in MIME format.

--528D1__D7E
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Attention All Staff Members:

You Must Respond By 5 P.M. Monday, August 16, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Staff Members, who respond to this
message before 5 P.M., Monday, August 16, 2004.

All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

    1-800-884-9510 by 5 P.M. Monday, August 16, 2004

The fast and powerful AT-2400 series Desktop features: 

      * Intel 2.0Ghz Processor for amazing speed and performance
      * 128MB DDR RAM,  --- Upgradeable to 1024
      * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
      * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW 
      * 1.44 Floppy disk drive
      * Next Generation Technology
      * ATI Premium video and sound
      * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
      * Soft Touch Keyboard and scroll mouse
      * Internet Ready
      * Network Ready
      * 1 Year parts and labor warranty
      * Priority customer service and tech support

MSRP $699 ........................................ Your Cost $297

How to qualify:

  1. You must be a Nonprofit Staff Member or Associate.
  2. All desktop computers will be available on a
     first come first serve basis.
  3. You must call 1-800-884-9510 by 5 P.M. Monday, August 16, 2004
     and we will hold the desktops you request on will call. 
  4. You are not obligated in any way.
  5. 100% Satisfaction Guaranteed.

Call Avtech Direct
1-800-884-9510 before 5 P.M. Monday, August 16, 2004

Visit our website at http://www.avtechdirectcomputers.com

If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp

Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--528D1__D7E--

Date: Thu, 12 Aug 2004 17:03:38 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development  Division
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], SCOTT Bancroft <[email-masked]>
Subject: Re: Speak now or forever hold your peace...
Sender: [email-masked]

Peter Sylvester wrote:

>>>tags > 30 create most likely some problems in decoders, too.
>>
>>You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
>>with decoders generated by a compiler.
> 
> 
> This is not a question of a bug, it is a question of whether
> low level routines can supports tags > 30.
> 
> This has not much to do whether the syntax is treated by a compiler
> but with the possibility of decoding larger value in low level routines
> in a situation where all practical well known syntaxes do not have 
> tags > 30, thus, the low level implementation of tag decoding can 
> assume that you have only one octet for a tag.
> 
> I have not seen any compiler that is able to link againt a low level
> decoder specific with the maximum tag length that can ever occur the
> given compilation environment. 
> 
> how many compilers can handle a context tag of about 2**130
> 
> But well, we are somehow getting out of scope of this discussion.

We may be out of scope, but since your assertion about decoders looked 
wrong to me, I checked with Bancroft Scott from OSS Nokalva and here is 
what he said:
-----
There are **MANY** ASN.1 specs that have tags in excess of 30.
I know of no commercial-grade ASN.1 toolkit, nor any of the
popular free ones, that suffers from such a deficiency.

In the early 1990's the implementor's organization in Europe, the U.S.A
(NIST Stable Implementation Guideline) and Asia agreed that ASN.1 specs
should not use tag numbers greater than 16383, and implicitly, that tools
should support tags of at least that size.  To the best of my knowledge
all commercial-grade and popular free ASN.1 toolkits support tags this
large.
-----

Olivier

From: "Faisal Maqsood" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace... 
Date: Thu, 12 Aug 2004 13:45:48 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Hi FD,

please see comments below:

Regards,
Faisal

==============================
----- Original Message -----
From: "Francis Dupont" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
Sent: Wednesday, August 11, 2004 21:08
Subject: Re: Speak now or forever hold your peace...

In your previous mail you wrote:

   => you should get the .... to for CertConfig. I have a concern about
                              too
   this: this gives two different ways to specify the parameters for
   an unique cert.

   [FM: No, By "....." I mean the remaining part of Query in draft 15 .

=> I mean the same thing(s).

   Yes this gives two different ways, but let me explain how this helps:

=> I understand your idea but with per cert checks/wantbacks why not
per cert isCA flag, etc.
[FM:
As I have already written that my puposed structure will come out
with new things. But as in current SCVP structure there are elements
provided only to facilitate the client to make single request/response in a
single file so that client can make his archives in a better way according
to their needs i.e. Refering to 3.2.5. To consider such elements the
purposed structure can benefit
the clients and it also saves time of client to make different requests and
also communication time will be reduced.
In addition you may see similar problem with TrustAnchors if client puts
three certificates in QueriedCerts and four certificates in TrustAnchors...
will it not make burden on server in DPD? Ofcourse it will.
You may imagine the real time requests/responses of more number of
QueriedCerts and TrustAnchors, so I am not happy with the existing structure
but it is all upto ASN.1 designers to consider such more serious things
present in existing structure.]

   IMHO the best option is just to accept one certificate per request.
   It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
   is already handled by references, we need only a way to share crls,
   i.e., define our own RevocationInfo reference system?

=> I put this again because it is a good summary of my opinion.

Regards

[email-masked]

Date: Thu, 12 Aug 2004 02:17:28 -0500
From: Nicolas Williams <[email-masked]>
To: Michael Myers <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Pki4ipsec] OCSP in IKEv2
Mail-Followup-To: Michael Myers <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Your I-D actually cleared up some confusion in the KRB WG over the
meaning of "OCSP tunnelling" and led to achievement of consensus on how
to add support for OCSP to PKINIT.  Thank you.

Nico
-- 

On Sat, Aug 07, 2004 at 10:21:32AM -0700, Michael Myers wrote:
> All,
> 
> The intersection of IPSEC with PKI is of recent interest.  Towards that
> dialog, Hannes Tschofenig and I have proposed how OCSP could be used to
> deliver certificate status in-band to IKEv2.  We were driven first to
> consider the important use case of EAP (i.e. the Road Warrior) but also
> considered the Peer-to-Peer case in order to develop a general solution.
> 
> This individual submission I-D can be found at:
> http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt
> 
> Two new certificate encoding types are proposed:  OCSP Responder Hash
> and OCSP Response.  An OCSP Responder Hash is sent in a CERTREQ,
> computed as trust anchor hashes are computed but sent in a separate
> CERTREQ.  A corresponding OCSP Response is sent back in its own CERT
> payload and in the context of the CERT payload carrying the
> participant's certificate.  That is, an IKEv2 participant sends both its
> cert and that cert's status in separate CERT payloads.
> 
> Hannes and I look forward to your comments and debate.  I've
> cross-posted due to intersecting interests but please post comments to
> the IPSEC list only.
> 
> Michael Myers
> 
> 
> _______________________________________________
> pki4ipsec mailing list
> [email-masked]
> http://honor.icsalabs.com/mailman/listinfo/pki4ipsec

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 13:58:26 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
I don't see any clause in 3379 that requires SCVP to support the
scenario you describe. In fact section 4.2 states "Protocols designed to
satisfy these requirements MAY include optional fields and/or extensions
to support relaying, re-direction or multicasting."

Therefore SCVP meets the 3379 requirements. The scenario you describe
requires at a minimum the rely server to have a new validation algorithm
because as you describe  it is not verifying the result itself but
verifying the DPV response from another server. Therefore you are at
liberty to define such extensions.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 9:51 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > Hi Peter,
* > The TSA and DPVs responses are both in the paragraph you refer to
and
* > both are outside the bounds of the validation algorithms defined
today
* > so do not constitute information useful to a relying party. So I
think
* > SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
* > does use such values as part of the validation process you can also
* > define how to return them in the response. The SVP response is
* > extensible so I am confident you can do that.
* 
* 
* The scenario is a local DPV server operating as a locally trusted
* interface like in OCSP. The DPV server has the knoweldge about
* which other DPV servers are to be contacted to validate the cert
* in question.
* 
* The DPV relay thus simply asks the external service (operated closely
* to a CA for example), and then simply confirms the result by
* telling its client that the cert is good 'because the other DPV told
it',
* and it includes the original DPV response.
* 
* This behaviour is IMO an essential feature for the different types
* of relaying.
* 
* it is not up to me to define these things: SCVP needs to support them
* to conform wityh 3379. That's why I propose simply to add a text
* with a response value containing a CMS content-type. I do not think
* that this should require another document.
* 
* 
* 
* 

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 10:36:14 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 10:24 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * To which value do you intialize max_path_length of point k in
6.1.2
* > * if you want to validate a CA cert that is used to signed another
CA?
* > *
* > [TF] SCVP supports all the inputs as defined in 6.1.1
* >
* 
* Are you saying that 3280 is broken?
[TF] no
* 
* My question is whether you can you validate a CA certificate
* of a partial path where you alreaduy know that you have a subCA.
[TF] We support path validation from defined roots down.
* 

Date: Wed, 11 Aug 2004 19:24:15 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> * To which value do you intialize max_path_length of point k in 6.1.2
> * if you want to validate a CA cert that is used to signed another CA?
> * 
> [TF] SCVP supports all the inputs as defined in 6.1.1
> 

Are you saying that 3280 is broken? 

My question is whether you can you validate a CA certificate
of a partial path where you alreaduy know that you have a subCA.

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 10:13:10 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 10:02 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* >
* > RFC3280, section 6.1.6 item k states
* >
* you mean 6.1.4 I guess.
* 
* > "Verify that the certificate is a CA certificate (as specified in a
* > basicConstraints extension or as verified out-of-band)."
* >
* > Therefore the server does use the Boolean in the basic constraints
* > extension to determine if the certificate is a CA or not. Therefore
use
* > of a Boolean with SCVP is in alignment with 3280.
* 
* To which value do you intialize max_path_length of point k in 6.1.2
* if you want to validate a CA cert that is used to signed another CA?
* 
[TF] SCVP supports all the inputs as defined in 6.1.1

Date: Wed, 11 Aug 2004 19:02:05 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> 
> RFC3280, section 6.1.6 item k states
> 
you mean 6.1.4 I guess.

> "Verify that the certificate is a CA certificate (as specified in a
> basicConstraints extension or as verified out-of-band)."
> 
> Therefore the server does use the Boolean in the basic constraints
> extension to determine if the certificate is a CA or not. Therefore use
> of a Boolean with SCVP is in alignment with 3280.

To which value do you intialize max_path_length of point k in 6.1.2
if you want to validate a CA cert that is used to signed another CA?

Date: Wed, 11 Aug 2004 18:50:32 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> Hi Peter,
> The TSA and DPVs responses are both in the paragraph you refer to and
> both are outside the bounds of the validation algorithms defined today
> so do not constitute information useful to a relying party. So I think
> SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
> does use such values as part of the validation process you can also
> define how to return them in the response. The SVP response is
> extensible so I am confident you can do that.

The scenario is a local DPV server operating as a locally trusted
interface like in OCSP. The DPV server has the knoweldge about
which other DPV servers are to be contacted to validate the cert
in question. 

The DPV relay thus simply asks the external service (operated closely
to a CA for example), and then simply confirms the result by
telling its client that the cert is good 'because the other DPV told it',
and it includes the original DPV response.

This behaviour is IMO an essential feature for the different types
of relaying. 

it is not up to me to define these things: SCVP needs to support them
to conform wityh 3379. That's why I propose simply to add a text
with a response value containing a CMS content-type. I do not think
that this should require another document.  

Content-class: urn:content-classes:message
Subject: RE: SCVP remarks.
Date: Wed, 11 Aug 2004 09:33:29 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
Let me repeat my previous posting which was after this mail.

[TF] Since you had not linked our discussion on the requestor field to
this section of 3379 before we have been at cross purposes. As Dennis
pointed out this field is intended for SCVP relay so the current text is
accurate for that purpose. It's a opaque blob to the server so
definition of any standard structures in this case was and is a
pointless exercise.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: SCVP remarks.
* 
* 
* 
* I'll repeat The purpose is not only relaying.
* 
* Using an opaque blob for the server is not conformant with the text
* and spirit of 3379. I had asked for those fields during the
* discussions of 3379, and the intention was by no means to have
* opaque blob but 'potentially global identifiers'.
* 
* 3379 clearly indicates that a server may possesses some logic to
* match these identiiers with the ones used for authentication.
* 
* An opaque blob does not allow IMO to implement any useful
interoperable
* interpretation by the server which serves to identify the
participating
* entities.
* 
* > [TF] Since you had not linked our discussion on the requestor field
to
* > this section of 3379 before we have been at cross purposes. As
Dennis
* > pointed out this field is intended for SCVP relay so the current
text is
* > accurate for that purpose. It's a opaque blob to the server so
* > definition of any standard structures in this case was and is a
* > pointless exercise.

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 09:25:20 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
The TSA and DPVs responses are both in the paragraph you refer to and
both are outside the bounds of the validation algorithms defined today
so do not constitute information useful to a relying party. So I think
SCVP 15 conforms to RFC3379.  Wherever you define the algorithm that
does use such values as part of the validation process you can also
define how to return them in the response. The SVP response is
extensible so I am confident you can do that.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 1) RFC 3379 says:
* > *    The DPV request MUST allow the client to request that the
server
* > *    include in its response additional information which will allow
* > *    relying parties not trusting the DPV server to be confident
that
* > the
* > *    certificate validation has correctly been performed.  Such
* > *    information may (not necessarily exclusively) consist of a
* > *    certification path, revocation status information from
authorized
* > CRL
* > *    issuers or authorized OCSP responders, revocation status
* > information
* > *    from CRL issuers or OCSP responders trusted under the
validation
* > *    policy, time-stamp tokens from TSAs responders trusted under
the
* > *    validation policy, or a DPV response from a DPV server that is
* > *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* > *
* > *    trusted under the validation policy.  When the certificate is
valid
* > *    according to the validation policy, the server MUST, upon
request,
* > *    include that information in the response.  However, the server
MAY
* > *    omit that information when the certificate is invalid or when
it
* > *    cannot determine the validity.
* > *
* > *    ==> no provision (as far as I see).
* >
* > [TF] Given that SCVP requires the server ensure that the validation
* > policy has been complied with and permits all the parameters for the
* > currently defined validation algorithms to be returned ( full
* > certificate path, CRLs, OCSP responses) then I consider SCVP to be
fully
* > compliant with 3379. There are no currently defined validation
* > algorithms which have a TSA response or a DPV response from another
SCVP
* > server as an input, however if such as algorithm were to be defined,
* > then the extension mechanisms within SCVP would permit TSA responses
or
* > DPV responses to be also returned.
* >
* 
* If you read the text above the XXX above I am not talking about TSAs.
* There has been a lengthy discussion about this requirement years ago
* with at least some understaning that a DPV server can operate in a
similar
* way as an OCSP server, thus returning DPV server responses have the
* similar functionality.
* 
* I suggest to return a CMS contenttype as one of the possible return
* values.
* 
* > Also which discussing the client requesting the validation
information
* > by value in section 3.2.5 states
* >
* > "include by value in the CVResponse  every aspect of the validation
* > policy"
* >
* >

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Wed, 11 Aug 2004 09:18:11 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,

RFC3280, section 6.1.6 item k states

"Verify that the certificate is a CA certificate (as specified in a
basicConstraints extension or as verified out-of-band)."

Therefore the server does use the Boolean in the basic constraints
extension to determine if the certificate is a CA or not. Therefore use
of a Boolean with SCVP is in alignment with 3280.

I would be happy to add an OID to allow a DPD client to request all
paths be returned so a DPD client can make more granular choices along
the lines you discuss.

Trevor

* -----Original Message-----
* From: Peter Sylvester [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 4:27 AM
* To: [email-masked]; Trevor Freeman
* Cc: [email-masked]
* Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
* 
* > * 3) In May 204 trevor wrote:
* > *
* > * > I think we can use the Cert sign bit in key usage so the is CA
bit
* > can
* > * > be removed from SCVP15
* > *
* > * which was not done.
* >
* >
* > [TF] Yes I reconsidered that position. Since the 3280 path
validation
* > algorithm uses the basic constrains extension as it's test for CA
* > certificates (3280, 6.1.4, k) and that algorithm is a mandatory
feature
* > for every SCVP validation algorithm, I concluded it was safer to use
the
* > same test rather than risk another based on key usage.
* >
* 
* The boolean isCA does not indicate at all how the server determines
* whether a cert is a CA cert. You may consider to at least reference
* what the server is supposed to perform as a test.
* 
* Since you returned to you original definition, please respond to
* my repeated suggestion to use an integer representing a minimal value
* for pathmenth in the basicconstraints instead of a boolean.
* 
* 
* > *
* > * 4) Somewhat related to this, and to the provisions to search in
DPD or
* > * validate
* > *    in DPV several types of extensions, I had proposed to
opetionally
* > * search
* > *    for the pathlength basicconstraint. if for example a client has
a
* > *    cert and a CA cert then one could use it to search only for CAs
* > that
* > *    have at least a pathlength of 1.
* > *
* >

Content-class: urn:content-classes:message
Subject: RE: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 09:06:23 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Faisal,
Since requestRefHash has a default value, it can be omitted from the
encoding and therefore does not result in bits on the wire.

Trevor

* -----Original Message-----
* From: Faisal Maqsood [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 3:06 AM
* To: Trevor Freeman; [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* Hi Trevor,
* 
* Thanks for the reply. In your sentence what is meant by encoded ? I
think
* If
* you make this element optional then this will reduce the size of SCVP
* Request.
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: "Trevor Freeman" <[email-masked]>
* To: "Trevor Freeman" <[email-masked]>; "Faisal
Maqsood"
* <[email-masked]>; <[email-masked]>; <[email-masked]>
* Sent: Tuesday, August 10, 2004 21:49
* Subject: RE: Speak now or forever hold your peace...
* 
* 
* > Sorry, one correction to this. requestRefHash is already defaulted
so is
* > not encoded i.e. there are no bits on the wire to save so it can say
as
* > it is.
* >
* > Trevor
* >
* > * -----Original Message-----
* > * From: [email-masked]
* > [mailto:[email-masked]]
* > * On Behalf Of Trevor Freeman
* > * Sent: Tuesday, August 10, 2004 8:39 AM
* > * To: Faisal Maqsood; [email-masked]; [email-masked]
* > * Subject: RE: Speak now or forever hold your peace...
* > *
* > *
* > *
* > * Hi Faisal,
* > * Thanks for this.
* > * Trevor
* > *
* > * * -----Original Message-----
* > * * From: [email-masked]
* > * [mailto:[email-masked]]
* > * * On Behalf Of Faisal Maqsood
* > * * Sent: Tuesday, August 10, 2004 3:51 AM
* > * * To: [email-masked]; [email-masked]
* > * * Subject: Re: Speak now or forever hold your peace...
* > * *
* > * *
* > * * Hi,
* > * *
* > * * Below are my points on SCVP-15:
* > * *
* > * * - In following structure why 'requestRefHash' is not tagged?[TF]
* > * Fixed
* > * * - Should 'IsCA' not be 'isCA'?[TF] already fixed
* > * * - Should 'SignResponse' not be 'signResponse'?[TF]  already
fixed
* > * * - Should there not be commas in tags 13 and 14?[TF]  already
fixed
* > * * - If we know default values for 'requestRefHash' and tagged 0 to
5,
* > * why we
* > * * are not making these as optional? To make them optional will
benifit
* > * for
* > * * low
* > * * network traffic and if these optional value are not inserted in
* > * request
* > * * server will automatically use default values.[TF]  fixed
* > * *
* > * * Query ::= SEQUENCE {
* > * *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
* > CertReference,
* > * *      checks                   CertChecks,
* > * *      wantBack                 WantBack,
* > * *      validationAlg            ValidationAlg,
* > * *      requestRefHash           BOOLEAN DEFAULT TRUE,
* > * *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
* > * *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
* > * *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
* > * *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
* > * *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
* > * *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
* > * *      serverContextInfo    [6] OCTET STRING OPTIONAL,
* > * *      validityTime         [7] GeneralizedTime OPTIONAL,
* > * *      trustAnchors         [8] TrustAnchors OPTIONAL,
* > * *      intermediateCerts    [9] CertBundle OPTIONAL,
* > * *      revInfos            [10] RevocationInfos OPTIONAL,
* > * *      keyUsage            [11] KeyUsage OPTIONAL,
* > * *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* > * *      queryExtensions     [13] Extensions OPTIONAL
* > * *      producedAt          [14] GeneralizedTime OPTIONAL
* > * *      validationPolRef    [15] ValidationPolRef OPTIONAL}
* > * *
* > * * - In following structure tags are not correct for 'attrCert' and
* > * 'acRef'?[TF]  fixed
* > * *
* > * *     CertReference ::= CHOICE {
* > * *       pkc                   PKCReference,
* > * *       ac                    ACReference }
* > * *
* > * *     PKCReference ::= CHOICE {
* > * *       cert              [1] Certificate,
* > * *       pkcRef            [2] ESSCertID }
* > * *
* > * *     ACReference ::= CHOICE {
* > * *       attrCert          [1] AttributeCertificate,
* > * *       acRef             [2] ESSCertID }
* > * *
* > * * - In above structure why tag start from 1 instead of 0 in
'cert'?
* > * *
* > * * - In structure below why 'requestor' tag starts from 1 instead
of
* > * 0?[TF]  fixed
* > * *
* > * *     CVResponse ::= SEQUENCE {
* > * *       scvpVersion           INTEGER,
* > * *       policyID              INTEGER,
* > * *       producedAt            GeneralizedTime,
* > * *       responseStatus        ResponseStatus,
* > * *       requestRef            RequestReference,
* > * *       requestor         [1] OCTET STRING OPTIONAL,
* > * *       responder         [2] OCTET STRING OPTIONAL,
* > * *       replyObjects      [3] ReplyObjects OPTIONAL,
* > * *       requestNonce      [4] OCTET STRING OPTIONAL,
* > * *       serverContextInfo [5] OCTET STRING OPTIONAL,
* > * *       valPolResponse    [6] ValPolicy OPTIONAL,
* > * *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
* > * *       respExtensions    [8] Extensions OPTIONAL }
* > * *
* > * * - In following structure should 'requestHash' tag not be start
from
* > 0
* > * * instead 1?[TF]  fixed
* > * *
* > * *     RequestReference ::= CHOICE {
* > * *       requestHash       [1] HashValue, -- hash of CVRequest
* > * *       fullRequest       [2] CVRequest }
* > * *
* > * * - In following structure should 'nextUpdate' tag not be start
from 0
* > * * instead 1?[TF]  fixed
* > * *
* > * *     CertReply ::= SEQUENCE {
* > * *       cert                       CertReference,
* > * *       replyStatus                ReplyStatus,
* > * *       replyValTime               GeneralizedTime,
* > * *       replyChecks                ReplyChecks,
* > * *       replyWantBacks             ReplyWantBacks,
* > * *       valAlg                     ValidationAlg,
* > * *       nextUpdate             [1] GeneralizedTime OPTIONAL,
* > * *       certReplyExtensions    [2] Extensions OPTIONAL }
* > * *
* > * * - In the following paragraph referenced section 3.2.7 should be
* > 3.2.15
* > * to
* > * * point CertBundle[TF]  fixed
* > * *
* > * *   The octet string value for the certification path used to
verify
* > * *   the certificate in the request, { id-swb 1 }, contains the
* > * *   CertBundle type.  The syntax and semantics of the CertBundle
type
* > * *   are described in section 3.2.7.
* > * *
* > * * Regards,
* > * * Faisal
* > * *
* > * * ----- Original Message -----
* > * * From: <[email-masked]>
* > * * To: <[email-masked]>
* > * * Sent: Thursday, August 05, 2004 05:06
* > * * Subject: SCVP: Speak now or forever hold your peace...
* > * *
* > * *
* > * * >
* > * * >
* > * * >
* > * * > Folks,
* > * * >
* > * * > It is time to get serious and finish up SCVP.  In the slides
* > * presented
* > * * at
* > * * our
* > * * > meeting this morning, the SCVP editors requested a "Definitive
and
* > * final
* > * * list
* > * * > of all issues from workgroup".  I believe that is a reasonable
* > * request.
* > * * Let's
* > * * > do our best to get that list documented ASAP, so that -16 can
be
* > our
* > * * *last*.
* > * * >
* > * * > I am requesting that everyone in the WG make time to review
SCVP
* > and
* > * * document
* > * * > any issues you find by Friday the 13th.  (I am not setting a
* > * deadline
* > * * for
* > * * > terminating discussion - it may take a few days to reach
consensus
* > * on
* > * * the
* > * * > issue list.  I am just trying to surface all the issues ASAP.)
* > Once
* > * the
* > * * issue
* > * * > list is stable, I am sure we can work out solutions.
* > * * >
* > * * > Please post all technical comments to the list.  Editorial
* > comments
* > * can
* > * * be
* > * * > sent to Trevor directly.  Include SCVP in the subject line
* > * regardless!
* > * * >
* > * * > Thanks,
* > * * >
* > * * > Tim Polk
* > * * >
* > *
* >

Date: Wed, 11 Aug 2004 18:00:45 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace...
Sender: [email-masked]

At least in some countries this part of the year is a vacation period, 
I think that 10 days is not a good proposal. 

> 
> Folks,
> 
> It is time to get serious and finish up SCVP.  In the slides presented at our 
> meeting this morning, the SCVP editors requested a "Definitive and final list 
> of all issues from workgroup".  I believe that is a reasonable request.  Let's 
> do our best to get that list documented ASAP, so that -16 can be our *last*.
> 
> I am requesting that everyone in the WG make time to review SCVP and document 
> any issues you find by Friday the 13th.  (I am not setting a deadline for 
> terminating discussion - it may take a few days to reach consensus on the 
> issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
> list is stable, I am sure we can work out solutions.
> 
> Please post all technical comments to the list.  Editorial comments can be 
> sent to Trevor directly.  Include SCVP in the subject line regardless! 
> 
> Thanks,
> 
> Tim Polk  
> 
> 

Date: Wed, 11 Aug 2004 17:55:56 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace...
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> > tags > 30 create most likely some problems in decoders, too.
> 
> You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
> with decoders generated by a compiler.

This is not a question of a bug, it is a question of whether
low level routines can supports tags > 30.

This has not much to do whether the syntax is treated by a compiler
but with the possibility of decoding larger value in low level routines
in a situation where all practical well known syntaxes do not have 
tags > 30, thus, the low level implementation of tag decoding can 
assume that you have only one octet for a tag.

I have not seen any compiler that is able to link againt a low level
decoder specific with the maximum tag length that can ever occur the
given compilation environment. 

how many compilers can handle a context tag of about 2**130

But well, we are somehow getting out of scope of this discussion.

Date: Wed, 11 Aug 2004 11:47:04 -0400
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked], PKIX <[email-masked]>
Subject: SCVP
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
(sorry if any of these are duplicates)<br>
<br>
Technical:<br>
<ol>
  <li>How are the queriedCerts, checks, and wantBack correlated?&nbsp; For
example: I send in four certs and I want a validated path back to the
root to be built, do I have to include id-stc-build-valid-pkc-path
three different times in checks?&nbsp; Ditto for the wantBack if I want the
same thing back?&nbsp; Or are we assuming all certs in querriedCerts will
want the same checks?&nbsp; If it's the 1st I think that something like "For
every CertReference in queriedCerts, a corresponding check must be
included" (in 3.2.2) - ditto for wantBack (3.2.3) - or something like
the "The 1st value in queriedCerts corresponds to the 1st value in
checks and wantBack, the 2nd to the 2nd, etc."&nbsp; If it's the later it
ought to say "Every certificate referred to in CertReference will have
the same checks and wantBacks applied" in 3.2.&nbsp; I'm not picky about the
particular words as long as you get my drift.</li>
  <li>3.2.12 should we be referencing the string prep stuff in some way?<br>
  </li>
</ol>
Editorial:<br>
<ol>
  <li>2. 3rd para replace "," at the end with "."</li>
  <li>3. 3rd para 2n sentence: "An overview of this structure is
provided below."&nbsp; Can we add something like "The definitive ASN.1 is
found in [CMS]" after "many details are not shown"?&nbsp; I know later on it
says the syntax and semantics are in [CMS] but I was hoping to see the
"definitive" part at the beginning and not the end.<br>
  </li>
  <li>3. 2nd para after authenticatedData example: add space between
profile and [PKIX-1].</li>
  <li>3. 2nd para after authenticatedData example keyusage blurb: Move
period that is after non-repudiation to end of line.<br>
  </li>
  <li>3.2.8 Any-Policy and Any-policy should be any-policy or is it
anypolicy?</li>
  <li>3.2.9 Add a space between extension and [PKIX... also add a
period after ].</li>
  <li>3.2.12.2 2nd para, remove space id-svp- and NameValAlg.<br>
  </li>
  <li>3.2.17 and 18 Add space between extension and [PKIX-1...<br>
  </li>
  <li>3.2.20 Add period to end of 2nd paragraph.</li>
  <li>3.6 Remove extra SCVP in 1st sentence.&nbsp; Also remove ".validation"
from the same sentence.</li>
  <li>4. Same as comment Ed #2.</li>
  <li>4.13 I think the apostrophe in client's shows up as&nbsp; special
character.&nbsp; Also add a period to the end of the paragraph.<br>
  </li>
  <li>4.13.2 remove ".validation" from 1st sentence.<br>
  </li>
  <li>9. Should we say that the following are in addition to the CMS
security considerations since this protocol is based on CMS?<br>
  </li>
  <li>10.1 [OpenPGP] should be removed as a normative reference since
it's not referenced anywhere in the document.</li>
</ol>
</body>
</html>

Date: Wed, 11 Aug 2004 17:30:45 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development  Division
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace...
Sender: [email-masked]

Peter Sylvester wrote:
>>   
>>=> we have the choice. We can begin by 123456 and put 999999 in the next.
>>
> 
> 
> I think that explicitly using the tags that would
> be used with AUTOMATIC tagging is not such a bad idea. 

Agree!

> tags > 30 create most likely some problems in decoders, too.

You mean: In decoders badly hand-coded. ;)  I'm not aware of such a bug 
with decoders generated by a compiler.

Olivier

From: "Faisal Maqsood" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 20:05:30 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Well FD ,

please see comments below:

Regards,
Faisal

==============================
----- Original Message -----
From: "Francis Dupont" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 11, 2004 18:36
Subject: Re: Speak now or forever hold your peace...

 In your previous mail you wrote:

   1. Client put all three certificates in Query of a single SCVP request
   and for want backs client puts all his required OIDs.

=> this suggests to spread most of the Query fields to a per cert
structure... I agree, IMHO only requestRefHash and signResponse are
clearly per CVRequest.

   2. Client generates three different SCVP requests with his requirement
   as stated in above case.

=> IMHO multiple SCVP requests are better at one exception: when you'd
like to get the whole thing in one CMS message. In fact the real issue
is that ASN.1 has no reference, so can't handle easily sharing
(one can say this is another consequence of the incredible incompetence
of ASN.1 designers in computer science :-).

   I would propose the following structure.

   Query ::= SEQUENCE {
    QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
    Checks     [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack OPTIONAL,
    .....
       }

   CertConfig::= SEQUENCE{
    Cert  CertReference,
    Checks      [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack   OPTIONAL
   }

=> you should get the .... to for CertConfig. I have a concern about
this: this gives two different ways to specify the parameters for
an unique cert.

[FM: No, By "....." I mean the remaining part of Query in draft 15 . Yes
this gives
two different ways, but let me explain how this helps:
    - Firstly for the case I mentioned above in my original email,
client
can use CertConfig optional elements i.e. checks & wantback to be
specified
for each certificate and not to use Query optional elements checks,
wantback.
    - Secondly for the case if client has multiple certificates and for
one
certificate he needs only certification path(s) while for all other
certificates client needs same other wantback, in this case client will
use
CertConfig optional elements checks, wantback only for first certificate
and
not for others but also client can use the Query optional elements
checks,
wantback to specify common wantback for other certificates (for which
client
has not used CertConfig optional elements).
By this way client has choice to control network trafic too.]

IMHO the best option is just to accept one certificate per request.
It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
is already handled by references, we need only a way to share crls,
i.e., define our own RevocationInfo reference system?

Regards

[email-masked]

Date: Wed, 11 Aug 2004 16:54:14 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development  Division
To: Francis Dupont <[email-masked]>
CC: Faisal Maqsood <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace...
Sender: [email-masked]

Francis Dupont wrote:

>  In your previous mail you wrote:
> 
>       - If we know default values for 'requestRefHash' and tagged 0 to 5, why
>    we are not making these as optional?
>    
>    => DEFAULT is similar to OPTIONAL, both are not always encoded according
>    to T-REC-X.680-200207 24.14 for instance.

24.14 deals with extension additions, but I think that your type has no 
extension marker.
The relevant subclauses are 24.10 and 24.11:
24.10	If OPTIONAL or DEFAULT are present, the corresponding value may be 
omitted from a value of the new type.
24.11	If DEFAULT occurs, the omission of a value for that type shall be 
exactly equivalent to the insertion of the value defined by "Value", 
which shall be a value notation for a value of the type defined by 
"Type" in the "NamedType" production sequence.

>        [FM: But DEFAULT is not same to OPTIONAL,
> 
> => not but they are described together in X.680.
> 
>    so it will be better to explicitly mention DEFAULT with OPTIONAL.
> 
> => I disagree and I don't understand, in the unlikely case it is legal (*),

It is illegal to have both OPTIONAL and DEFAULT applied to the same 
component of a structured type.

> what it means. (*) X.680 syntax excludes DEFAULT with OPTIONAL.
> 
>    Although tagged elements are by default OPTIONAL]
> 
> => ??? I don't think the OPTIONAL keyword is optional!

I didn't understand either what "tagged elements are by default 
OPTIONAL" means.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

Date: Wed, 11 Aug 2004 16:31:50 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace...
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>    
> => we have the choice. We can begin by 123456 and put 999999 in the next.
> 

I think that explicitly using the tags that would
be used with AUTOMATIC tagging is not such a bad idea. 

tags > 30 create most likely some problems in decoders, too.

From: Francis Dupont <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 16:16:43 +0200
Sender: [email-masked]

 In your previous mail you wrote:

      - If we know default values for 'requestRefHash' and tagged 0 to 5, why
   we are not making these as optional?
   
   => DEFAULT is similar to OPTIONAL, both are not always encoded according
   to T-REC-X.680-200207 24.14 for instance.
       [FM: But DEFAULT is not same to OPTIONAL,

=> not but they are described together in X.680.

   so it will be better to explicitly mention DEFAULT with OPTIONAL.

=> I disagree and I don't understand, in the unlikely case it is legal (*),
what it means. (*) X.680 syntax excludes DEFAULT with OPTIONAL.

   Although tagged elements are by default OPTIONAL]

=> ??? I don't think the OPTIONAL keyword is optional!
   
      - In above structure why tag start from 1 instead of 0 in 'cert'?
   
   => we have the choice. We can begin by 123456 and put 999999 in the next.
       [FM: Same goes for OPTIONAL? right, but it is better to follow some
   standard way so that readers can feel comfortable that they have not skipped
   or author has not skipped some thing]
   
=> this is really a matter of taste. IMHO the authors still stand well
between dictatorship and anarchy (:-).
   
Regards
  
[email-masked]

From: "Faisal Maqsood" <[email-masked]>
To: "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 19:06:48 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Well FD ,

please see comments below:

Regards,
Faisal

==============================

In your previous mail you wrote:

   Below are my points on SCVP-15:

   - In following structure why 'requestRefHash' is not tagged?

=> this is the first one so we don't need to tag it.
    [FM: what is logic that first one do not need to be tag?]

   - Should 'IsCA' not be 'isCA'?
   - Should 'SignResponse' not be 'signResponse'?
   - Should there not be commas in tags 13 and 14?

=> typos (I found then too).

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why
we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.
    [FM: But DEFAULT is not same to OPTIONAL, so it will be better to
explicitly mention DEFAULT with OPTIONAL. Although tagged elements are by
default OPTIONAL]

   - In following structure tags are not correct for 'attrCert' and 'acRef'?

       CertReference ::= CHOICE {
         pkc                   PKCReference,
         ac                    ACReference }

       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }

       ACReference ::= CHOICE {
         attrCert          [1] AttributeCertificate,
         acRef             [2] ESSCertID }

=> do you mean they should be 3 and 4?
    [FM: Yes]

   - In above structure why tag start from 1 instead of 0 in 'cert'?

=> we have the choice. We can begin by 123456 and put 999999 in the next.
    [FM: Same goes for OPTIONAL? right, but it is better to follow some
standard way so that readers can feel comfortable that they have not skipped
or author has not skipped some thing]

   - In structure below why 'requestor' tag starts from 1 instead of 0?

   - In following structure should 'requestHash' tag not be start from 0
   instead 1?

   - In following structure should 'nextUpdate' tag not be start from 0
   instead 1?

=> same.

   - In the following paragraph referenced section 3.2.7 should be 3.2.15 to
   point CertBundle

=> I missed this one.

Regards

[email-masked]

From: Francis Dupont <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 15:36:57 +0200
Sender: [email-masked]

 In your previous mail you wrote:

   1. Client put all three certificates in Query of a single SCVP request
   and for want backs client puts all his required OIDs.

=> this suggests to spread most of the Query fields to a per cert
structure... I agree, IMHO only requestRefHash and signResponse are
clearly per CVRequest.

   2. Client generates three different SCVP requests with his requirement
   as stated in above case.
   
=> IMHO multiple SCVP requests are better at one exception: when you'd
like to get the whole thing in one CMS message. In fact the real issue
is that ASN.1 has no reference, so can't handle easily sharing
(one can say this is another consequence of the incredible incompetence
of ASN.1 designers in computer science :-).

   I would propose the following structure.
   
   Query ::= SEQUENCE {
    QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
    Checks     [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack OPTIONAL,
    .....
       }
   
   CertConfig::= SEQUENCE{
    Cert  CertReference,
    Checks      [0] CertChecks OPTIONAL,
    WantBack    [1] WantBack   OPTIONAL
   }
   
=> you should get the .... to for CertConfig. I have a concern about
this: this gives two different ways to specify the parameters for
an unique cert.
   
IMHO the best option is just to accept one certificate per request.
It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
is already handled by references, we need only a way to share crls,
i.e., define our own RevocationInfo reference system?

Regards

[email-masked]

From: Francis Dupont <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 15:13:12 +0200
Sender: [email-masked]

 In your previous mail you wrote:

   Below are my points on SCVP-15:
   
   - In following structure why 'requestRefHash' is not tagged?

=> this is the first one so we don't need to tag it.

   - Should 'IsCA' not be 'isCA'?
   - Should 'SignResponse' not be 'signResponse'?
   - Should there not be commas in tags 13 and 14?

=> typos (I found then too).

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.

   - In following structure tags are not correct for 'attrCert' and 'acRef'?
   
       CertReference ::= CHOICE {
         pkc                   PKCReference,
         ac                    ACReference }
   
       PKCReference ::= CHOICE {
         cert              [1] Certificate,
         pkcRef            [2] ESSCertID }
   
       ACReference ::= CHOICE {
         attrCert          [1] AttributeCertificate,
         acRef             [2] ESSCertID }
   
=> do you mean they should be 3 and 4?

   - In above structure why tag start from 1 instead of 0 in 'cert'?
   
=> we have the choice. We can begin by 123456 and put 999999 in the next.

   - In structure below why 'requestor' tag starts from 1 instead of 0?
   
   - In following structure should 'requestHash' tag not be start from 0
   instead 1?
   
   - In following structure should 'nextUpdate' tag not be start from 0
   instead 1?
   
=> same.
   
   - In the following paragraph referenced section 3.2.7 should be 3.2.15 to
   point CertBundle
   
=> I missed this one.

Regards

[email-masked]

From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 14:40:43 +0200
Sender: [email-masked]

Here are editorial issues:

 - in 2 "request- response" -> "request-response"
  "validation request," -> "validation request."
 - in 3 SCVPRequest -> CVRequest (IMHO better than SCVP request)
   "request i.e." -> "request, i.e.,"
 - in 3.2 and in every places the fields are listed: update the
   list(s) in order to follow the current definition!
 - in 3.2.9 I am not sure that to use a BOOLEAN with a DEFAULT is
   a correct way to handle a field with 3 different possible values,
   i.e., can the DEFAULT override the "missing" value? BTW it works
   with OpenSSL but OpenSSL ASN.1 is not as standard as it should be.
 - in 3.2.9 the first sentence doesn't parse. IMHO there is an extra
   "certificate" word (last one).
 - in 3.2.10 I have two concerns:
   * the field should not be in query because it is about the response
     so the whole request. For instance what does happen formally when
     the field is set to different values in different queries of the
     same request.
   * not only DPD and DPV abbrevs must be expanded but I strongly suggest
     a reference to the RFC ([RQMTS])
 - in 3.3.12.1 "an valAlgId" -> "a valAlgId"
 - in 3.2.18 I suggest to contact the pki4ipsec WG where the EKU is
   an hot topic in order to know what id-kp to use (including none).
 - in 3.2.21 please specify what error to return (ReplyStatus 6?,
   in this case fix the error definition, i.e., add URI to OID).
 - in 3.6 and 4.13.2 I can't parse "PKIX-1.validation"
 - in 4 where is the certificate field in AuthenticatedData?
 - in 4.5 first paragraph: the hash doesn't cover encapsulated content
   and authenticated attributes, but only CVRequest. I suggest to remove
   the two statements refering to CMS.
 - in 4.8.4 we must explain the differences between Unknown and Unavailable
   or at least put the reference to the document where it is explained.
 - in 4.13 not ASCII betwen client and "s knowledge"
 - in 4.13 missing final "."
 - in 4.13.1 "a implementation" -> "an implementation"
 - in 5 and 6 please use either "Server" and "Validation" in titles.
 - in 6 polResponse -> PolResponse
 - in 6.8 "request i.e." -> "request, i.e.,",
   "requestors nonce" -> "requestor nonce" (or 's)
 - in 9 serverContextInformation -> serverContextInfo

Regards

[email-masked]

From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 13:48:54 +0200
Sender: [email-masked]

Here are ASN.1 & co typos and suggestions: first letter of a field in
lower case, of a type in upper case, plural for [wW]antBack.
 - 3.2 title Query -> query
 - in 3.2: [wW]antBack -> [wW]antBacks, IsCA -> isCA,
   SignResponse -> signResponse
   missing "," after queryExtensions and producedAt (same in 8)
 - in 3.2.3, including the title, [wW]antBack -> [wW]antBacks
 - put 3.2.12 before 3.2.4 (to follow the field order)
 - in 3.2.12.2 KeyPurposedId -> keyPurposedId (in definition and text),
   ValidationNames -> validationNames
 - in 3.2.16 riType -> reType, riValue -> reValue
 - in 3.3 and 4.6 title Requestor -> requestor
 - in 4 id-ct-scvp-psResponse -> id-ct-scvp-certValResponse (twice)
 - in 4 and 8, missing "," after validationPolRef
 - in 4.5.2 text PSRequest -> CVRequest
 - in 4.8.5, including the title, [rR]eplyWantBack -> [rR]eplyWantBacks
   (note this is *not* a suggestion, cf 4.8 where are the plurals
    and there is a ReplyWantBack type too: caution!)
 - in 4.11 IsCA -> isCA
 - in 4.11 and 8 trustAnchors should be OPTIONAL (because in the second usage,
   PolResponse, there already is a trustAnchors field).
 - in 6 and in 6.2, including title, DefaultPolicyID -> defaultPolicyID
 - in 6.7 AuthPolRefBy{OID,URI} -> authPolRefBy{OID,URI}
 - in 8 (extra typos):
   * Query: valalidationAlg -> validationAlg
            keyusage -> keyUsage
 - in B application/scvp-{request,response} ->
        application/cv-{request,response}

Regards

[email-masked]

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 16:53:17 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Hi,

Sorry for the long email but it is important.

Let's imagine of an SCVP client which puts three certificates in an SCVP
request message and in the reply it wants:
- only certification path(s) for the first certificate and
- only validated path for second certificate and
- only revocation status and OCSP/CRL used for third certificate.

I think to do this client has two options:

1. Client put all three certificates in Query of a single SCVP request
and for want backs client puts all his required OIDs.
2. Client generates three different SCVP requests with his requirement
as stated in above case.

If client uses method 1, it will make burden on SCVP Server (In this
case server has to collect all the information as stated by the want
backs OIDs for all the certificates)

If client uses method 2, it makes burden on Client (In this case the
client has to set different configs for each different request)

Note: This is just an example, there may be more complex use cases like
when involving ESSCertIDs, attribute certificates etc in the
combination.

Regarding this confusion/restriction in the protocol, I already sent an
email to the group list with subject "SCVP Structure Suggestions" but
may be subject was not good or what so ever, I did not get any response
of that email.

Now with this thread call, I again request to consider these cases
before new release.

>>>>> Relevant Suggestion Again >>>>>
In the CVRequest->Query one can specify Checks and WantBack.

I believe the Request ASNStructure should be similar to the strategy
used in the CVResponse->CertReply i.e CertChecks and WantBack should
also be present along with each certificate being validated in the
request message.

I would propose the following structure.

Query ::= SEQUENCE {
 QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
 Checks     [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack OPTIONAL,
 .....
    }

CertConfig::= SEQUENCE{
 Cert  CertReference,
 Checks      [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack   OPTIONAL
}

Note: by placing CertChecks and WantBack according to above has
following benefits:

- User can define WantBack, CertChecks for each Certificate separately
providing greater flexibility. The CVResponse->CertReply ASN structure
already supports seperate WantBack, CertChecks for each Certificate.

-  WantBack, CertChecks inside CVRequest->Query ASN Structure should
remain to provide default settings but would be OPTIONAL. If in
CertConfig one does not provide WantBack and CertChecks then these
default values (CVRequest->Query->WantBack,
CVRequest->Query->CertChecks) MUST be present and used.

- Benefit of providing Checks and WantBack inside Query would be to
allow some or all of the Cert inside CertConfig to use default Checks +
WantBack settings thus reducing CVRequest size and thus reduces network
load.
<<<<<

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>

Date: Wed, 11 Aug 2004 13:34:12 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SCVP remarks.
Cc: [email-masked]
Sender: [email-masked]

Sorry for the bad subject in the previous mail.

> * 1) RFC 3379 says:
> *    The DPV request MUST allow the client to request that the server
> *    include in its response additional information which will allow
> *    relying parties not trusting the DPV server to be confident that
> the
> *    certificate validation has correctly been performed.  Such
> *    information may (not necessarily exclusively) consist of a
> *    certification path, revocation status information from authorized
> CRL
> *    issuers or authorized OCSP responders, revocation status
> information
> *    from CRL issuers or OCSP responders trusted under the validation
> *    policy, time-stamp tokens from TSAs responders trusted under the
> *    validation policy, or a DPV response from a DPV server that is
> *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> * 
> *    trusted under the validation policy.  When the certificate is valid
> *    according to the validation policy, the server MUST, upon request,
> *    include that information in the response.  However, the server MAY
> *    omit that information when the certificate is invalid or when it
> *    cannot determine the validity.
> * 
> *    ==> no provision (as far as I see).
> 
> [TF] Given that SCVP requires the server ensure that the validation
> policy has been complied with and permits all the parameters for the
> currently defined validation algorithms to be returned ( full
> certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
> compliant with 3379. There are no currently defined validation
> algorithms which have a TSA response or a DPV response from another SCVP
> server as an input, however if such as algorithm were to be defined,
> then the extension mechanisms within SCVP would permit TSA responses or
> DPV responses to be also returned. 
> 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

> Also which discussing the client requesting the validation information
> by value in section 3.2.5 states
> 
> "include by value in the CVResponse  every aspect of the validation
> policy"
> 
> 

Date: Wed, 11 Aug 2004 13:33:50 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SCVP remarks.
Cc: [email-masked]
Sender: [email-masked]

Sorry for the bad subject in the previous mail.

> * 3) In May 204 trevor wrote:
> * 
> * > I think we can use the Cert sign bit in key usage so the is CA bit
> can
> * > be removed from SCVP15
> * 
> * which was not done.
> 
> 
> [TF] Yes I reconsidered that position. Since the 3280 path validation
> algorithm uses the basic constrains extension as it's test for CA
> certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
> for every SCVP validation algorithm, I concluded it was safer to use the
> same test rather than risk another based on key usage.
> 

The boolean isCA does not indicate at all how the server determines
whether a cert is a CA cert. You may consider to at least reference 
what the server is supposed to perform as a test.  

Since you returned to you original definition, please respond to
my repeated suggestion to use an integer representing a minimal value
for pathmenth in the basicconstraints instead of a boolean.   

> * 
> * 4) Somewhat related to this, and to the provisions to search in DPD or
> * validate
> *    in DPV several types of extensions, I had proposed to opetionally
> * search
> *    for the pathlength basicconstraint. if for example a client has a
> *    cert and a CA cert then one could use it to search only for CAs
> that
> *    have at least a pathlength of 1.
> * 
> 

Date: Wed, 11 Aug 2004 13:27:17 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> * 1) RFC 3379 says:
> *    The DPV request MUST allow the client to request that the server
> *    include in its response additional information which will allow
> *    relying parties not trusting the DPV server to be confident that
> the
> *    certificate validation has correctly been performed.  Such
> *    information may (not necessarily exclusively) consist of a
> *    certification path, revocation status information from authorized
> CRL
> *    issuers or authorized OCSP responders, revocation status
> information
> *    from CRL issuers or OCSP responders trusted under the validation
> *    policy, time-stamp tokens from TSAs responders trusted under the
> *    validation policy, or a DPV response from a DPV server that is
> *                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> * 
> *    trusted under the validation policy.  When the certificate is valid
> *    according to the validation policy, the server MUST, upon request,
> *    include that information in the response.  However, the server MAY
> *    omit that information when the certificate is invalid or when it
> *    cannot determine the validity.
> * 
> *    ==> no provision (as far as I see).
> 
> [TF] Given that SCVP requires the server ensure that the validation
> policy has been complied with and permits all the parameters for the
> currently defined validation algorithms to be returned ( full
> certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
> compliant with 3379. There are no currently defined validation
> algorithms which have a TSA response or a DPV response from another SCVP
> server as an input, however if such as algorithm were to be defined,
> then the extension mechanisms within SCVP would permit TSA responses or
> DPV responses to be also returned. 
> 

If you read the text above the XXX above I am not talking about TSAs.
There has been a lengthy discussion about this requirement years ago
with at least some understaning that a DPV server can operate in a similar
way as an OCSP server, thus returning DPV server responses have the
similar functionality. 

I suggest to return a CMS contenttype as one of the possible return values.

> Also which discussing the client requesting the validation information
> by value in section 3.2.5 states
> 
> "include by value in the CVResponse  every aspect of the validation
> policy"
> 
> 

Date: Wed, 11 Aug 2004 13:27:04 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: SCVP remarks.
Cc: [email-masked]
Sender: [email-masked]

I'll repeat The purpose is not only relaying.

Using an opaque blob for the server is not conformant with the text
and spirit of 3379. I had asked for those fields during the
discussions of 3379, and the intention was by no means to have
opaque blob but 'potentially global identifiers'. 

3379 clearly indicates that a server may possesses some logic to 
match these identiiers with the ones used for authentication. 

An opaque blob does not allow IMO to implement any useful interoperable 
interpretation by the server which serves to identify the participating
entities. 

> [TF] Since you had not linked our discussion on the requestor field to
> this section of 3379 before we have been at cross purposes. As Dennis
> pointed out this field is intended for SCVP relay so the current text is
> accurate for that purpose. It's a opaque blob to the server so
> definition of any standard structures in this case was and is a
> pointless exercise.

Date: Wed, 11 Aug 2004 13:27:09 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Cc: [email-masked]
Sender: [email-masked]

> * 3) In May 204 trevor wrote:
> * 
> * > I think we can use the Cert sign bit in key usage so the is CA bit
> can
> * > be removed from SCVP15
> * 
> * which was not done.
> 
> 
> [TF] Yes I reconsidered that position. Since the 3280 path validation
> algorithm uses the basic constrains extension as it's test for CA
> certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
> for every SCVP validation algorithm, I concluded it was safer to use the
> same test rather than risk another based on key usage.
> 

The boolean isCA does not indicate at all how the server determines
whether a cert is a CA cert. You may consider to at least reference 
what the server is supposed to perform as a test.  

Since you returned to you original definition, please respond to
my repeated suggestion to use an integer representing a minimal value
for pathmenth in the basicconstraints instead of a boolean.   

> * 
> * 4) Somewhat related to this, and to the provisions to search in DPD or
> * validate
> *    in DPV several types of extensions, I had proposed to opetionally
> * search
> *    for the pathlength basicconstraint. if for example a client has a
> *    cert and a CA cert then one could use it to search only for CAs
> that
> *    have at least a pathlength of 1.
> * 
> 

From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 12:16:14 +0200
Sender: [email-masked]

Here are the ASN.1 bugs:
 - CertReference is an ambiguous CHOICE. In a previous version
   one tried to solve the ambiguity by changing the ACReference tags
   to 3 and 4 (I don't know if this is really allowed or recognized
   by compilers, of course it works but as I'd like to get the reference
   stuff a bit extended perhaps it is better to tag the CertReference itself).
 - responseStatus 50 is missing in 4.4
 - change the fullPolRequestUnsuported into fullPolResponseUnsuported in 4.4
   and 8
 - the cert field in CertReply is CertReference in 4.8 and ReplyCertificate
   in 8. I prefer the 8 (and previous draft) version because it is a
   simple way to enforce the return of the whole certificate. There are
   many ways to fix this:
   - just fix 8
   - same but add a want back to get the certificate itself (note that with
     IKE the certificate itself is useful only if the name validation
     algorithm doesn't work, and in the other case the public key is
     enough).
   - just fix 8 and adding in 4.8.1 that the whole certificate is mandatory
   - go back to previous draft, i.e., fix 4.8 and 4.8.1
   (note: I prefer the second solution (and get the validation algorithm
    error issue fixed!))
 - change the valAlg of CertReply (4.8 and 8) into validationAlg
 - fix the name of Pol{icies}Response in 5
 - add the i to validationPolices (to get validationPolicies) in 6 and
   add a subsection describing it between 6.5 and 6.6

Regards

[email-masked]

From: "Faisal Maqsood" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace...
Date: Wed, 11 Aug 2004 15:05:56 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Hi Trevor,

Thanks for the reply. In your sentence what is meant by encoded ? I think If
you make this element optional then this will reduce the size of SCVP
Request.

Regards,
Faisal

----- Original Message -----
From: "Trevor Freeman" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>; "Faisal Maqsood"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 10, 2004 21:49
Subject: RE: Speak now or forever hold your peace...

> Sorry, one correction to this. requestRefHash is already defaulted so is
> not encoded i.e. there are no bits on the wire to save so it can say as
> it is.
>
> Trevor
>
> * -----Original Message-----
> * From: [email-masked]
> * On Behalf Of Trevor Freeman
> * Sent: Tuesday, August 10, 2004 8:39 AM
> * To: Faisal Maqsood; [email-masked]; [email-masked]
> * Subject: RE: Speak now or forever hold your peace...
> *
> *
> *
> * Hi Faisal,
> * Thanks for this.
> * Trevor
> *
> * * -----Original Message-----
> * * From: [email-masked]
> * [mailto:[email-masked]]
> * * On Behalf Of Faisal Maqsood
> * * Sent: Tuesday, August 10, 2004 3:51 AM
> * * To: [email-masked]; [email-masked]
> * * Subject: Re: Speak now or forever hold your peace...
> * *
> * *
> * * Hi,
> * *
> * * Below are my points on SCVP-15:
> * *
> * * - In following structure why 'requestRefHash' is not tagged?[TF]
> * Fixed
> * * - Should 'IsCA' not be 'isCA'?[TF] already fixed
> * * - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
> * * - Should there not be commas in tags 13 and 14?[TF]  already fixed
> * * - If we know default values for 'requestRefHash' and tagged 0 to 5,
> * why we
> * * are not making these as optional? To make them optional will benifit
> * for
> * * low
> * * network traffic and if these optional value are not inserted in
> * request
> * * server will automatically use default values.[TF]  fixed
> * *
> * * Query ::= SEQUENCE {
> * *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
> CertReference,
> * *      checks                   CertChecks,
> * *      wantBack                 WantBack,
> * *      validationAlg            ValidationAlg,
> * *      requestRefHash           BOOLEAN DEFAULT TRUE,
> * *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
> * *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
> * *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
> * *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
> * *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
> * *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
> * *      serverContextInfo    [6] OCTET STRING OPTIONAL,
> * *      validityTime         [7] GeneralizedTime OPTIONAL,
> * *      trustAnchors         [8] TrustAnchors OPTIONAL,
> * *      intermediateCerts    [9] CertBundle OPTIONAL,
> * *      revInfos            [10] RevocationInfos OPTIONAL,
> * *      keyUsage            [11] KeyUsage OPTIONAL,
> * *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
> * *      queryExtensions     [13] Extensions OPTIONAL
> * *      producedAt          [14] GeneralizedTime OPTIONAL
> * *      validationPolRef    [15] ValidationPolRef OPTIONAL}
> * *
> * * - In following structure tags are not correct for 'attrCert' and
> * 'acRef'?[TF]  fixed
> * *
> * *     CertReference ::= CHOICE {
> * *       pkc                   PKCReference,
> * *       ac                    ACReference }
> * *
> * *     PKCReference ::= CHOICE {
> * *       cert              [1] Certificate,
> * *       pkcRef            [2] ESSCertID }
> * *
> * *     ACReference ::= CHOICE {
> * *       attrCert          [1] AttributeCertificate,
> * *       acRef             [2] ESSCertID }
> * *
> * * - In above structure why tag start from 1 instead of 0 in 'cert'?
> * *
> * * - In structure below why 'requestor' tag starts from 1 instead of
> * 0?[TF]  fixed
> * *
> * *     CVResponse ::= SEQUENCE {
> * *       scvpVersion           INTEGER,
> * *       policyID              INTEGER,
> * *       producedAt            GeneralizedTime,
> * *       responseStatus        ResponseStatus,
> * *       requestRef            RequestReference,
> * *       requestor         [1] OCTET STRING OPTIONAL,
> * *       responder         [2] OCTET STRING OPTIONAL,
> * *       replyObjects      [3] ReplyObjects OPTIONAL,
> * *       requestNonce      [4] OCTET STRING OPTIONAL,
> * *       serverContextInfo [5] OCTET STRING OPTIONAL,
> * *       valPolResponse    [6] ValPolicy OPTIONAL,
> * *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
> * *       respExtensions    [8] Extensions OPTIONAL }
> * *
> * * - In following structure should 'requestHash' tag not be start from
> 0
> * * instead 1?[TF]  fixed
> * *
> * *     RequestReference ::= CHOICE {
> * *       requestHash       [1] HashValue, -- hash of CVRequest
> * *       fullRequest       [2] CVRequest }
> * *
> * * - In following structure should 'nextUpdate' tag not be start from 0
> * * instead 1?[TF]  fixed
> * *
> * *     CertReply ::= SEQUENCE {
> * *       cert                       CertReference,
> * *       replyStatus                ReplyStatus,
> * *       replyValTime               GeneralizedTime,
> * *       replyChecks                ReplyChecks,
> * *       replyWantBacks             ReplyWantBacks,
> * *       valAlg                     ValidationAlg,
> * *       nextUpdate             [1] GeneralizedTime OPTIONAL,
> * *       certReplyExtensions    [2] Extensions OPTIONAL }
> * *
> * * - In the following paragraph referenced section 3.2.7 should be
> 3.2.15
> * to
> * * point CertBundle[TF]  fixed
> * *
> * *   The octet string value for the certification path used to verify
> * *   the certificate in the request, { id-swb 1 }, contains the
> * *   CertBundle type.  The syntax and semantics of the CertBundle type
> * *   are described in section 3.2.7.
> * *
> * * Regards,
> * * Faisal
> * *
> * * ----- Original Message -----
> * * From: <[email-masked]>
> * * To: <[email-masked]>
> * * Sent: Thursday, August 05, 2004 05:06
> * * Subject: SCVP: Speak now or forever hold your peace...
> * *
> * *
> * * >
> * * >
> * * >
> * * > Folks,
> * * >
> * * > It is time to get serious and finish up SCVP.  In the slides
> * presented
> * * at
> * * our
> * * > meeting this morning, the SCVP editors requested a "Definitive and
> * final
> * * list
> * * > of all issues from workgroup".  I believe that is a reasonable
> * request.
> * * Let's
> * * > do our best to get that list documented ASAP, so that -16 can be
> our
> * * *last*.
> * * >
> * * > I am requesting that everyone in the WG make time to review SCVP
> and
> * * document
> * * > any issues you find by Friday the 13th.  (I am not setting a
> * deadline
> * * for
> * * > terminating discussion - it may take a few days to reach consensus
> * on
> * * the
> * * > issue list.  I am just trying to surface all the issues ASAP.)
> Once
> * the
> * * issue
> * * > list is stable, I am sure we can work out solutions.
> * * >
> * * > Please post all technical comments to the list.  Editorial
> comments
> * can
> * * be
> * * > sent to Trevor directly.  Include SCVP in the subject line
> * regardless!
> * * >
> * * > Thanks,
> * * >
> * * > Tim Polk
> * * >
> *
>

From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace... 
Date: Wed, 11 Aug 2004 11:51:53 +0200
Sender: [email-masked]

I have many comments about the SCVP draft 15: in its current case
IMHO it should not be sent to the RFC editor. I've tried to classify
comments into major problems, ASN.1 problems and editorial problems.
Here are the major problems (other issues will be next messages):
 - IMHO we *really* need an explanation about the validation policy
   and algorithm terms. Currently this is spread between lines among
   the whole document.
 - there is no hint about how to return validation algorithm errors,
   two examples:
   * what happens when isCA is set in a query and the entity type of
     the certificate is not the right one? One can believe the status
     (want back 3) should be set to invalid but a more detailed report
     should be fine and this doesn't answer to the next point.
   * how to use the name validation algorithm errors? They are defined
     but there is no place to put them in response/reply.
 - the signature stuff is completely misleading. I believe there are two
   usage modes:
   * SCVP over HTTP/HTTPS where only raw requests/responses (i.e.,
     CVRequest/CVResponse/... in DER) are sent without any embedded
     signature or MAC.
   * SCVP over CMS where SignedData and AuthenticatedData can bind
     a signature or MAC to encapsulated requests/responses.
   All discussions about signature, for instance the signResponse stuff,
   are about the second mode only.
 - in the HTTP/HTTPS mode I can't see any benefit to validate more than
   one certificate per exchange. In order to keep SCVP simple we can add
   this as an implementation hint, can't we?
 - I'd like to use SCVP in order to handle certificate validation in
   IKE, including the new Hash and URL stuff of IKEv2. But this doesn't
   work with ESSCertID because it uses an optional IssuerSerial in place
   of the URL. I'd like to get an extended way to give a pointer to
   a certificate in addition to its SHA-1 hash.

Regards

[email-masked]

Content-class: urn:content-classes:message
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 09:49:13 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Faisal Maqsood" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sorry, one correction to this. requestRefHash is already defaulted so is
not encoded i.e. there are no bits on the wire to save so it can say as
it is.

Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Trevor Freeman
* Sent: Tuesday, August 10, 2004 8:39 AM
* To: Faisal Maqsood; [email-masked]; [email-masked]
* Subject: RE: Speak now or forever hold your peace...
* 
* 
* 
* Hi Faisal,
* Thanks for this.
* Trevor
* 
* * -----Original Message-----
* * From: [email-masked]
* [mailto:[email-masked]]
* * On Behalf Of Faisal Maqsood
* * Sent: Tuesday, August 10, 2004 3:51 AM
* * To: [email-masked]; [email-masked]
* * Subject: Re: Speak now or forever hold your peace...
* *
* *
* * Hi,
* *
* * Below are my points on SCVP-15:
* *
* * - In following structure why 'requestRefHash' is not tagged?[TF]
* Fixed
* * - Should 'IsCA' not be 'isCA'?[TF] already fixed
* * - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
* * - Should there not be commas in tags 13 and 14?[TF]  already fixed
* * - If we know default values for 'requestRefHash' and tagged 0 to 5,
* why we
* * are not making these as optional? To make them optional will benifit
* for
* * low
* * network traffic and if these optional value are not inserted in
* request
* * server will automatically use default values.[TF]  fixed
* *
* * Query ::= SEQUENCE {
* *      queriedCerts             SEQUENCE SIZE (1..MAX) OF
CertReference,
* *      checks                   CertChecks,
* *      wantBack                 WantBack,
* *      validationAlg            ValidationAlg,
* *      requestRefHash           BOOLEAN DEFAULT TRUE,
* *      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
* *      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
* *      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
* *      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
* *      IsCA                 [4] BOOLEAN DEFAULT FALSE,
* *      SignResponse         [5] BOOLEAN DEFAULT TRUE,
* *      serverContextInfo    [6] OCTET STRING OPTIONAL,
* *      validityTime         [7] GeneralizedTime OPTIONAL,
* *      trustAnchors         [8] TrustAnchors OPTIONAL,
* *      intermediateCerts    [9] CertBundle OPTIONAL,
* *      revInfos            [10] RevocationInfos OPTIONAL,
* *      keyUsage            [11] KeyUsage OPTIONAL,
* *      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
* *      queryExtensions     [13] Extensions OPTIONAL
* *      producedAt          [14] GeneralizedTime OPTIONAL
* *      validationPolRef    [15] ValidationPolRef OPTIONAL}
* *
* * - In following structure tags are not correct for 'attrCert' and
* 'acRef'?[TF]  fixed
* *
* *     CertReference ::= CHOICE {
* *       pkc                   PKCReference,
* *       ac                    ACReference }
* *
* *     PKCReference ::= CHOICE {
* *       cert              [1] Certificate,
* *       pkcRef            [2] ESSCertID }
* *
* *     ACReference ::= CHOICE {
* *       attrCert          [1] AttributeCertificate,
* *       acRef             [2] ESSCertID }
* *
* * - In above structure why tag start from 1 instead of 0 in 'cert'?
* *
* * - In structure below why 'requestor' tag starts from 1 instead of
* 0?[TF]  fixed
* *
* *     CVResponse ::= SEQUENCE {
* *       scvpVersion           INTEGER,
* *       policyID              INTEGER,
* *       producedAt            GeneralizedTime,
* *       responseStatus        ResponseStatus,
* *       requestRef            RequestReference,
* *       requestor         [1] OCTET STRING OPTIONAL,
* *       responder         [2] OCTET STRING OPTIONAL,
* *       replyObjects      [3] ReplyObjects OPTIONAL,
* *       requestNonce      [4] OCTET STRING OPTIONAL,
* *       serverContextInfo [5] OCTET STRING OPTIONAL,
* *       valPolResponse    [6] ValPolicy OPTIONAL,
* *       validationPolRef  [7] ValidationPolicyRef OPTIONAL
* *       respExtensions    [8] Extensions OPTIONAL }
* *
* * - In following structure should 'requestHash' tag not be start from
0
* * instead 1?[TF]  fixed
* *
* *     RequestReference ::= CHOICE {
* *       requestHash       [1] HashValue, -- hash of CVRequest
* *       fullRequest       [2] CVRequest }
* *
* * - In following structure should 'nextUpdate' tag not be start from 0
* * instead 1?[TF]  fixed
* *
* *     CertReply ::= SEQUENCE {
* *       cert                       CertReference,
* *       replyStatus                ReplyStatus,
* *       replyValTime               GeneralizedTime,
* *       replyChecks                ReplyChecks,
* *       replyWantBacks             ReplyWantBacks,
* *       valAlg                     ValidationAlg,
* *       nextUpdate             [1] GeneralizedTime OPTIONAL,
* *       certReplyExtensions    [2] Extensions OPTIONAL }
* *
* * - In the following paragraph referenced section 3.2.7 should be
3.2.15
* to
* * point CertBundle[TF]  fixed
* *
* *   The octet string value for the certification path used to verify
* *   the certificate in the request, { id-swb 1 }, contains the
* *   CertBundle type.  The syntax and semantics of the CertBundle type
* *   are described in section 3.2.7.
* *
* * Regards,
* * Faisal
* *
* * ----- Original Message -----
* * From: <[email-masked]>
* * To: <[email-masked]>
* * Sent: Thursday, August 05, 2004 05:06
* * Subject: SCVP: Speak now or forever hold your peace...
* *
* *
* * >
* * >
* * >
* * > Folks,
* * >
* * > It is time to get serious and finish up SCVP.  In the slides
* presented
* * at
* * our
* * > meeting this morning, the SCVP editors requested a "Definitive and
* final
* * list
* * > of all issues from workgroup".  I believe that is a reasonable
* request.
* * Let's
* * > do our best to get that list documented ASAP, so that -16 can be
our
* * *last*.
* * >
* * > I am requesting that everyone in the WG make time to review SCVP
and
* * document
* * > any issues you find by Friday the 13th.  (I am not setting a
* deadline
* * for
* * > terminating discussion - it may take a few days to reach consensus
* on
* * the
* * > issue list.  I am just trying to surface all the issues ASAP.)
Once
* the
* * issue
* * > list is stable, I am sure we can work out solutions.
* * >
* * > Please post all technical comments to the list.  Editorial
comments
* can
* * be
* * > sent to Trevor directly.  Include SCVP in the subject line
* regardless!
* * >
* * > Thanks,
* * >
* * > Tim Polk
* * >
* 

Content-class: urn:content-classes:message
Subject: RE: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 08:38:48 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Faisal,
Thanks for this.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 10, 2004 3:51 AM
* To: [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* Hi,
* 
* Below are my points on SCVP-15:
* 
* - In following structure why 'requestRefHash' is not tagged?[TF]
Fixed
* - Should 'IsCA' not be 'isCA'?[TF] already fixed
* - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
* - Should there not be commas in tags 13 and 14?[TF]  already fixed
* - If we know default values for 'requestRefHash' and tagged 0 to 5,
why we
* are not making these as optional? To make them optional will benifit
for
* low 
* network traffic and if these optional value are not inserted in
request
* server will automatically use default values.[TF]  fixed
* 
* Query ::= SEQUENCE {
*      queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
*      checks                   CertChecks,
*      wantBack                 WantBack,
*      validationAlg            ValidationAlg,
*      requestRefHash           BOOLEAN DEFAULT TRUE,
*      fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
*      inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
*      requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
*      ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
*      IsCA                 [4] BOOLEAN DEFAULT FALSE,
*      SignResponse         [5] BOOLEAN DEFAULT TRUE,
*      serverContextInfo    [6] OCTET STRING OPTIONAL,
*      validityTime         [7] GeneralizedTime OPTIONAL,
*      trustAnchors         [8] TrustAnchors OPTIONAL,
*      intermediateCerts    [9] CertBundle OPTIONAL,
*      revInfos            [10] RevocationInfos OPTIONAL,
*      keyUsage            [11] KeyUsage OPTIONAL,
*      extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
*      queryExtensions     [13] Extensions OPTIONAL
*      producedAt          [14] GeneralizedTime OPTIONAL
*      validationPolRef    [15] ValidationPolRef OPTIONAL}
* 
* - In following structure tags are not correct for 'attrCert' and
'acRef'?[TF]  fixed
* 
*     CertReference ::= CHOICE {
*       pkc                   PKCReference,
*       ac                    ACReference }
* 
*     PKCReference ::= CHOICE {
*       cert              [1] Certificate,
*       pkcRef            [2] ESSCertID }
* 
*     ACReference ::= CHOICE {
*       attrCert          [1] AttributeCertificate,
*       acRef             [2] ESSCertID }
* 
* - In above structure why tag start from 1 instead of 0 in 'cert'?
* 
* - In structure below why 'requestor' tag starts from 1 instead of
0?[TF]  fixed
* 
*     CVResponse ::= SEQUENCE {
*       scvpVersion           INTEGER,
*       policyID              INTEGER,
*       producedAt            GeneralizedTime,
*       responseStatus        ResponseStatus,
*       requestRef            RequestReference,
*       requestor         [1] OCTET STRING OPTIONAL,
*       responder         [2] OCTET STRING OPTIONAL,
*       replyObjects      [3] ReplyObjects OPTIONAL,
*       requestNonce      [4] OCTET STRING OPTIONAL,
*       serverContextInfo [5] OCTET STRING OPTIONAL,
*       valPolResponse    [6] ValPolicy OPTIONAL,
*       validationPolRef  [7] ValidationPolicyRef OPTIONAL
*       respExtensions    [8] Extensions OPTIONAL }
* 
* - In following structure should 'requestHash' tag not be start from 0
* instead 1?[TF]  fixed
* 
*     RequestReference ::= CHOICE {
*       requestHash       [1] HashValue, -- hash of CVRequest
*       fullRequest       [2] CVRequest }
* 
* - In following structure should 'nextUpdate' tag not be start from 0
* instead 1?[TF]  fixed
* 
*     CertReply ::= SEQUENCE {
*       cert                       CertReference,
*       replyStatus                ReplyStatus,
*       replyValTime               GeneralizedTime,
*       replyChecks                ReplyChecks,
*       replyWantBacks             ReplyWantBacks,
*       valAlg                     ValidationAlg,
*       nextUpdate             [1] GeneralizedTime OPTIONAL,
*       certReplyExtensions    [2] Extensions OPTIONAL }
* 
* - In the following paragraph referenced section 3.2.7 should be 3.2.15
to
* point CertBundle[TF]  fixed
* 
*   The octet string value for the certification path used to verify
*   the certificate in the request, { id-swb 1 }, contains the
*   CertBundle type.  The syntax and semantics of the CertBundle type
*   are described in section 3.2.7.
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: <[email-masked]>
* To: <[email-masked]>
* Sent: Thursday, August 05, 2004 05:06
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* >
* >
* >
* > Folks,
* >
* > It is time to get serious and finish up SCVP.  In the slides
presented
* at
* our
* > meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* > of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* > do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* >
* > I am requesting that everyone in the WG make time to review SCVP and
* document
* > any issues you find by Friday the 13th.  (I am not setting a
deadline
* for
* > terminating discussion - it may take a few days to reach consensus
on
* the
* > issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* > list is stable, I am sure we can work out solutions.
* >
* > Please post all technical comments to the list.  Editorial comments
can
* be
* > sent to Trevor directly.  Include SCVP in the subject line
regardless!
* >
* > Thanks,
* >
* > Tim Polk
* >

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Speak now or forever hold your peace...
Date: Tue, 10 Aug 2004 15:51:25 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

Hi,

Below are my points on SCVP-15:

- In following structure why 'requestRefHash' is not tagged?
- Should 'IsCA' not be 'isCA'?
- Should 'SignResponse' not be 'signResponse'?
- Should there not be commas in tags 13 and 14?
- If we know default values for 'requestRefHash' and tagged 0 to 5, why we
are not making these as optional? To make them optional will benifit for low
network traffic and if these optional value are not inserted in request
server will automatically use default values.

Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

- In following structure tags are not correct for 'attrCert' and 'acRef'?

    CertReference ::= CHOICE {
      pkc                   PKCReference,
      ac                    ACReference }

    PKCReference ::= CHOICE {
      cert              [1] Certificate,
      pkcRef            [2] ESSCertID }

    ACReference ::= CHOICE {
      attrCert          [1] AttributeCertificate,
      acRef             [2] ESSCertID }

- In above structure why tag start from 1 instead of 0 in 'cert'?

- In structure below why 'requestor' tag starts from 1 instead of 0?

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL
      respExtensions    [8] Extensions OPTIONAL }

- In following structure should 'requestHash' tag not be start from 0
instead 1?

    RequestReference ::= CHOICE {
      requestHash       [1] HashValue, -- hash of CVRequest
      fullRequest       [2] CVRequest }

- In following structure should 'nextUpdate' tag not be start from 0
instead 1?

    CertReply ::= SEQUENCE {
      cert                       CertReference,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      valAlg                     ValidationAlg,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

- In the following paragraph referenced section 3.2.7 should be 3.2.15 to
point CertBundle

  The octet string value for the certification path used to verify
  the certificate in the request, { id-swb 1 }, contains the
  CertBundle type.  The syntax and semantics of the CertBundle type
  are described in section 3.2.7.

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

>
>
>
> Folks,
>
> It is time to get serious and finish up SCVP.  In the slides presented at
our
> meeting this morning, the SCVP editors requested a "Definitive and final
list
> of all issues from workgroup".  I believe that is a reasonable request.
Let's
> do our best to get that list documented ASAP, so that -16 can be our
*last*.
>
> I am requesting that everyone in the WG make time to review SCVP and
document
> any issues you find by Friday the 13th.  (I am not setting a deadline for
> terminating discussion - it may take a few days to reach consensus on the
> issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
> list is stable, I am sure we can work out solutions.
>
> Please post all technical comments to the list.  Editorial comments can be
> sent to Trevor directly.  Include SCVP in the subject line regardless!
>
> Thanks,
>
> Tim Polk
>

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 20:33:37 -0400
Importance: Normal
Sender: [email-masked]

Thanks you, David.  Well put and properly corrected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Monday, August 09, 2004 4:43 PM
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

Woman: without her, man is nothing.
Woman, without her man, is nothing.
     -- from "Eats, Shoots & Leaves"

Punctuation is often helpful and sometimes essential.  I believe Santosh
meant:

   As to the meaning of nextUpdate, I always use the field as:
   "absent other security mechanisms, freshness of CRL and windows
   of CRL substitution attack is no worse than nextUpdate."

Julien Stern wrote:

> On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
 > ...
>>As to the meaning of nextUpdate, I always use the field as absent 
>>other security mechanisms freshness of CRL and windows of CRL 
>>substitution attack is no worse than nextUpdate.
> 
> 
> ??? Sorry, I just don't get that part :)
> 
> --
> Julien
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP: Speak now or forever hold your peace...
Date: Mon, 9 Aug 2004 13:48:37 -0700
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Please note my email address has changed. I can be reached on either
[email-masked] or [email-masked]. Anything sent
to my old address of [email-masked] ends up in the bit
bucket (don't ask).

Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of [email-masked]
* Sent: Wednesday, August 04, 2004 5:06 PM
* To: [email-masked]
* Subject: SCVP: Speak now or forever hold your peace...
* 
* 
* 
* 
* Folks,
* 
* It is time to get serious and finish up SCVP.  In the slides presented
at
* our
* meeting this morning, the SCVP editors requested a "Definitive and
final
* list
* of all issues from workgroup".  I believe that is a reasonable
request.
* Let's
* do our best to get that list documented ASAP, so that -16 can be our
* *last*.
* 
* I am requesting that everyone in the WG make time to review SCVP and
* document
* any issues you find by Friday the 13th.  (I am not setting a deadline
for
* terminating discussion - it may take a few days to reach consensus on
the
* issue list.  I am just trying to surface all the issues ASAP.)  Once
the
* issue
* list is stable, I am sure we can work out solutions.
* 
* Please post all technical comments to the list.  Editorial comments
can be
* sent to Trevor directly.  Include SCVP in the subject line regardless!
* 
* Thanks,
* 
* Tim Polk

Date: Mon, 09 Aug 2004 16:42:59 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Sender: [email-masked]

Woman: without her, man is nothing.
Woman, without her man, is nothing.
     -- from "Eats, Shoots & Leaves"

Punctuation is often helpful and sometimes essential.  I believe
Santosh meant:

   As to the meaning of nextUpdate, I always use the field as:
   "absent other security mechanisms, freshness of CRL and windows
   of CRL substitution attack is no worse than nextUpdate."

Julien Stern wrote:

> On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
 > ...
>>As to the meaning of nextUpdate, I always use the field as absent other
>>security mechanisms freshness of CRL and windows of CRL substitution attack
>>is no worse than nextUpdate.
> 
> 
> ??? Sorry, I just don't get that part :)
> 
> --
> Julien
> 

Date: Mon, 09 Aug 2004 15:18:57 -0500
To: "Ietf-pkix" <[email-masked]>
From: "Housley" <[email-masked]>
Subject:  
Sender: [email-masked]

----------elecdzmjhwxamkeinjmw
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
new  price<br><br>

<br>
</body></html>

----------elecdzmjhwxamkeinjmw
Content-Type: application/octet-stream; name="price_08.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price_08.zip"

----------elecdzmjhwxamkeinjmw--

Date: Mon, 09 Aug 2004 13:07:12 -0500
To: "Ietf-pkix" <[email-masked]>
From: "Smb" <[email-masked]>
Subject:  
Sender: [email-masked]

----------jizavpmhxpgrdzlrtoca
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
new price<br><br>

<br>
</body></html>

----------jizavpmhxpgrdzlrtoca
Content-Type: application/octet-stream; name="price2.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="price2.zip"

----------jizavpmhxpgrdzlrtoca--

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 18:59:43 +0200
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 09, 2004 at 12:21:30PM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> nextUpdate and nonce are different.

Santosh,

Of course they are ! We were arguing about whether they were "separate"
or not. I believe that nonces add almost no value if you use nextUpdate,
and are critical when nextUpdate is absent.
If nextUpdate indicate when new information will be available, there is
no risk of replay attack in between anyway.

> As to the meaning of nextUpdate, I always use the field as absent other
> security mechanisms freshness of CRL and windows of CRL substitution attack
> is no worse than nextUpdate.

??? Sorry, I just don't get that part :)

--
Julien

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julien Stern
> Sent: Monday, August 09, 2004 10:27 AM
> To: [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> > 
> > Julien:
> > 
> > Nonces help with the freshness of the revocation information.  For 
> > example, a Responder could poll or CA could push CRLs using SSL, in 
> > which case there is no old CRL substitution threat.  Thus, the 
> > Responder could get out of cycle (i.e., CRL issues prior to the next 
> > update) and use that later information.
> > 
> > Thus, it is important to keep the concept of next update and nonce 
> > separate.
> 
> Santosh,
> 
> All right, but then, what is the nextUpdate field supposed to mean for the
> client ? My understanding was that the nextUpdate field meant more or less:
> this information is valid and can be cached until this time.
> 
> If one publishes CRL every day with a difference between thisUpdate and
> nextUpdate of one week, I believe that the vast majorities of the clients
> will only actually pick one CRL out of seven, as they will cache the
> information until the nextUpdate.
> 
> If an OCSP was to feed itself on daily CRLs like that, it could set a
> nextUpdate of one day instead of one week, and if it does not want clients
> to cache information, it should not set nextUpdate.
> 
> If not yet convinced that the nextUpdate and the nonces are so separate.
> Either I'm not grasping exactly the signification of nextUpdate or I really
> do not see the combined use of nonces and the nextUpdate field.
> 
> --
> Julien
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 12:21:30 -0400
Importance: Normal
Sender: [email-masked]

Julien:

nextUpdate and nonce are different.

As to the meaning of nextUpdate, I always use the field as absent other
security mechanisms freshness of CRL and windows of CRL substitution attack
is no worse than nextUpdate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Monday, August 09, 2004 10:27 AM
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> Nonces help with the freshness of the revocation information.  For 
> example, a Responder could poll or CA could push CRLs using SSL, in 
> which case there is no old CRL substitution threat.  Thus, the 
> Responder could get out of cycle (i.e., CRL issues prior to the next 
> update) and use that later information.
> 
> Thus, it is important to keep the concept of next update and nonce 
> separate.

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for the
client ? My understanding was that the nextUpdate field meant more or less:
this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the clients
will only actually pick one CRL out of seven, as they will cache the
information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set a
nextUpdate of one day instead of one week, and if it does not want clients
to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I really
do not see the combined use of nonces and the nextUpdate field.

--
Julien

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 16:26:41 +0200
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> Nonces help with the freshness of the revocation information.  For example,
> a Responder could poll or CA could push CRLs using SSL, in which case there
> is no old CRL substitution threat.  Thus, the Responder could get out of
> cycle (i.e., CRL issues prior to the next update) and use that later
> information.
> 
> Thus, it is important to keep the concept of next update and nonce separate.

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for
the client ? My understanding was that the nextUpdate field meant more
or less: this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the
clients will only actually pick one CRL out of seven, as they will cache
the information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set
a nextUpdate of one day instead of one week, and if it does not want
clients to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I
really do not see the combined use of nonces and the nextUpdate field.

--
Julien

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 09:46:47 -0400
Importance: Normal
Sender: [email-masked]

PKIs I have been involved with, commit to publish CRL when there is a key
compromise immediately.

Of course, none of them have had compromises yet.

But, they do issue CRL reasonably well before next update.

It is typical to have a next update as this update + 7 days, but the actual
publication within 24 to 48 hours.

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]] 
Sent: Monday, August 09, 2004 5:25 AM
To: 'Julien Stern'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: About the Nonce issue in OCSPv1

> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:04
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > Julien:
> >
> > I have a problem with the proposal since you can have a "live" mode
and
> > still some latency in the revocation information as bounded by the
next
> > Update field.
> >
> > An example of such situation is when the responder is not the CA and
> uses
> > the CRL as the means of obtaining the revocation information.
> 
> Santosh,
> 
> this example would typically fall into the "caching" mode in the 
> terminology below. I do not see any advantage to use nonces when the 
> information is backed up by CRLs anyway. Because you know the CRL will 
> not change until what is indicated in its "nextUpdate" field, sending 
> a nonce-less OCSP reply should not expose you to any replay attack.
>

What about emergency CRLs which may be issued before the next official
"nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Does anyone have an idea of what percentage of PKIs really use emergency
CRLs? 

Regards,
Liaquat

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 09:43:38 -0400
Importance: Normal
Sender: [email-masked]

Julien:

Nonces help with the freshness of the revocation information.  For example,
a Responder could poll or CA could push CRLs using SSL, in which case there
is no old CRL substitution threat.  Thus, the Responder could get out of
cycle (i.e., CRL issues prior to the next update) and use that later
information.

Thus, it is important to keep the concept of next update and nonce separate.

-----Original Message-----
From: Julien Stern [mailto:[email-masked]] 
Sent: Monday, August 09, 2004 5:04 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> Julien:
> 
> I have a problem with the proposal since you can have a "live" mode 
> and still some latency in the revocation information as bounded by the 
> next Update field.
> 
> An example of such situation is when the responder is not the CA and 
> uses the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the terminology
below. I do not see any advantage to use nonces when the information is
backed up by CRLs anyway. Because you know the CRL will not change until
what is indicated in its "nextUpdate" field, sending a nonce-less OCSP reply
should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases, because
they are meant to protect against replay attacks that do not exist if (i)
there is a nextUpdate field (ii) no status change will occur before the
nextUpdate.

Note that if there is a status change before the nextUpdate, then clients
that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate field,
because there is no time frame during which the information may be cached by
the client. And in this case, you need nonces to defend against replay
attacks.
 
> Please note that 2560 does not provide any standard for obtaining 
> revocation information.  nextUpdate relates to how the OCSP Responder 
> obtains and processes revocation information where as nonce relates to 
> how the OCSP Responder produces responses.

Well, the RFC says:

   - nextUpdate: The time at or before which newer information will be
                    available about the status of the certificate

will essentially says "my reply is valid until nextUpdate". (So, why use
nonces here ...)

and 

   If nextUpdate is not set, the responder is indicating that newer
      revocation information is available all the time.

and in this case, nonces are vital, because the message is not intrinsically
protected as were those containing the nextUpdate field.

--
Julien

> On Behalf Of David Engberg
> Sent: Saturday, August 07, 2004 6:09 PM
> Cc: [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in 
> an OCSP response may have value for clients, even when a nonce is 
> used. For example, even a client who uses nonces to partially mitigate 
> against freshness-related attacks may wish to locally cache responses 
> for some period of time.  The "nextUpdate" field may give some 
> guidance to the client to indicate an upper bound on safe local 
> caching.
> 
> Previous proposals suggested using a new response extension to signal 
> cache/live server support.  Overloading the "nextUpdate" field for 
> this purpose allows us to avoid adding any new syntactic elements, but 
> a new field or extension would permit the continued use of 
> "nextUpdate" in all settings.
> 
> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> > Dear PKIX list,
> >
> > I had closely followed the long discussion about OCSP nonce problems 
> > that occured on the list around sep to dec 2003, and recently saw in 
> > the minutes of the WG meeting that OCSPv1 was to be clarified on 
> > that matter.
> >
> > I would like to submit the following to your appreciation. I believe 
> > that the following clarification (interpretation ? :)) of RFC2560 
> > solves all nonce/replay attack problems, without modifying the 
> > protocol or adding new extensions, and is fairly consistent with 
> > existing client and server implementations and hopefully with the 
> > spirit of the RFC.
> >
> > Naturally, comments are welcome and you can feel free to do whatever 
> > you want with what's below, notably dumping it into oblivion ;)
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> >
> > General
> > -------
> > The CRL approach to revocation checking has two principal drawbacks: 
> > the first one is that one needs to download a full CRL in order to 
> > check a single certificate and the second is that a CRL does not 
> > provide timely information (there is always a time frame during 
> > which a revoked certificate is not yet present in the CRL). The OCSP 
> > allows to overcome one or both of these drawbacks, depending on the 
> > mode in which it is used.
> >
> > An OCSP server can be configured in two different modes: the 
> > "caching" mode and the "live" mode. The live mode means that the 
> > server has access to up to date information and will always provide 
> > it. The caching mode means that the information obtained from the 
> > server has a delay with respect to the up to date information.
> >
> > The caching mode overcomes the bandwidth problem associated with 
> > CRL, but does not ensure timely information. The live mode solves 
> > both problem, but naturally is more computationaly expensive than 
> > the caching one. Typically, the caching mode would be used when the 
> > source of revocation information are CRLs but could also be used for 
> > efficiency reason when timely information is available.
> >
> > A server MUST NOT operate in caching and live mode at the same time.
> >
> > Clarifying requirements for caching OCSP servers
> > -----------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> present.
> >   It should indicate the expiration date of the (cached) information 
> > validity.
> > - the nonce extension can (and should) be ignored
> >
> > Clarifying requirement for live OCSP servers
> > --------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> absent,
> >   thus indicating the information is live
> > - live servers MUST support the nonce extension
> >
> > Client behavior
> > ---------------
> > If a client does not care about timely information, but simply 
> > wishes to save bandwidth, he MAY send a request without the Nonce 
> > extension.
> >
> > However, the behavior that clients SHOULD follow is:
> >
> > 1) Send a request with a Nonce;
> >
> > 2) If the response contains a Nonce, check that the Nonce matches 
> > the one sent. If they do not, reject the response, otherwise, the 
> > client is ensured to have timely information;
> >
> > 3) If the response does not contain a Nonce, check that all the 
> > SingleReponse elements contain a nextUpdate field, if not reject; 
> > otherwise, the client knows that the information is not timely but 
> > has, for each certificate, the time frame during which this 
> > information is deemed valid. Rejection or acceptance can be decided 
> > based on a local policy specifying, for example, acceptable time 
> > frames.
> >
> > About the replay attacks
> > ------------------------
> > One of the main issue that was raised during the previous 
> > discussions was to enable both server modes (Caching and Live) 
> > without prior knowledge of the client without more than one network 
> > interaction, while preventing replay attacks.
> >
> > Two different mecanisms are in fact in place to prevent replay
> > attacks: the nonces and the nextUpdate field. The nextUpdate field 
> > places an upper limit on the time for which replay attacks are 
> > possible. However, because they are only used by caching servers, a 
> > replay attack would simply provide the same information as the 
> > server itself would. If the nextUpdate field is absent, then the 
> > server is live and must have included a nonce in its reply to 
> > prevent replay attacks with this message.
> >
> > The danger may occurs when a message corresponding to one type of 
> > protection is replaced by a replayed message corresponding to the 
> > other. But in fact, there is only one configuration in which this 
> > may lead to a security risk:
> >
> > - A client sends a nonceless request
> > - An attacker replies with a previously intercepted live response
> >
> > In that case, the client can still check that the producedAt and 
> > thisUpdate fields are recent enough to mitigate the attack... At any 
> > rate, clients should always send requests with nonce if they want 
> > security...
> >

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>
Cc: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 12:18:43 +0100
Importance: Normal
Sender: [email-masked]

> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:50
> To: Liaquat Khan
> Cc: 'Santosh Chokhani'; [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Mon, Aug 09, 2004 at 10:25:23AM +0100, Liaquat Khan wrote:
> >
> >
> > > On Behalf Of Julien Stern
> > > Sent: 09 August 2004 10:04
> > > To: Santosh Chokhani
> > > Cc: [email-masked]
> > > Subject: Re: About the Nonce issue in OCSPv1
> > >
> > >
> > > On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > > > Julien:
> > > >
> > > > I have a problem with the proposal since you can have a "live"
mode
> > and
> > > > still some latency in the revocation information as bounded by
the
> > next
> > > > Update field.
> > > >
> > > > An example of such situation is when the responder is not the CA
and
> > > uses
> > > > the CRL as the means of obtaining the revocation information.
> > >
> > > Santosh,
> > >
> > > this example would typically fall into the "caching" mode in the
> > > terminology below. I do not see any advantage to use nonces when
the
> > > information is backed up by CRLs anyway. Because you know the CRL
will
> > > not change until what is indicated in its "nextUpdate" field,
sending
> > > a nonce-less OCSP reply should not expose you to any replay
attack.
> > >
> >
> > What about emergency CRLs which may be issued before the next
official
> > "nextUpdate", and pushed by the CRL issuer to the OCSP responder?
> 
> Yes, that might be a problem depending on the client behavior. I guess
> most clients would cache answers until the nextUpdate. If you want
> an "emergency" information to be propagated, it seems you would need
> a real "live" (and nonced) OCSP responder...
> 

Yes, this was the point I was trying to make, in such cases the OCSP
responder although working from CRLs, would still find it worthwhile to
use nonces.   

> > Does anyone have an idea of what percentage of PKIs really use
emergency
> > CRLs?
> Well, I don't ;)
> --
> Julien

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 11:49:52 +0200
To: Liaquat Khan <[email-masked]>
Cc: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], Liaquat Khan <[email-masked]>, 'Santosh Chokhani' <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Aug 09, 2004 at 10:25:23AM +0100, Liaquat Khan wrote:
> > On Behalf Of Julien Stern
> > Sent: 09 August 2004 10:04
> > To: Santosh Chokhani
> > Cc: [email-masked]
> > Subject: Re: About the Nonce issue in OCSPv1
> > 
> > 
> > On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > > Julien:
> > >
> > > I have a problem with the proposal since you can have a "live" mode
> and
> > > still some latency in the revocation information as bounded by the
> next
> > > Update field.
> > >
> > > An example of such situation is when the responder is not the CA and
> > uses
> > > the CRL as the means of obtaining the revocation information.
> > 
> > Santosh,
> > 
> > this example would typically fall into the "caching" mode in the
> > terminology below. I do not see any advantage to use nonces when the
> > information is backed up by CRLs anyway. Because you know the CRL will
> > not change until what is indicated in its "nextUpdate" field, sending
> > a nonce-less OCSP reply should not expose you to any replay attack.
> >
> 
> What about emergency CRLs which may be issued before the next official
> "nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Yes, that might be a problem depending on the client behavior. I guess
most clients would cache answers until the nextUpdate. If you want
an "emergency" information to be propagated, it seems you would need
a real "live" (and nonced) OCSP responder...

> Does anyone have an idea of what percentage of PKIs really use emergency
> CRLs? 

Well, I don't ;)
 
--
Julien

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Mon, 9 Aug 2004 10:25:23 +0100
Importance: Normal
Sender: [email-masked]

> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:04
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> > Julien:
> >
> > I have a problem with the proposal since you can have a "live" mode
and
> > still some latency in the revocation information as bounded by the
next
> > Update field.
> >
> > An example of such situation is when the responder is not the CA and
> uses
> > the CRL as the means of obtaining the revocation information.
> 
> Santosh,
> 
> this example would typically fall into the "caching" mode in the
> terminology below. I do not see any advantage to use nonces when the
> information is backed up by CRLs anyway. Because you know the CRL will
> not change until what is indicated in its "nextUpdate" field, sending
> a nonce-less OCSP reply should not expose you to any replay attack.
>

What about emergency CRLs which may be issued before the next official
"nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Does anyone have an idea of what percentage of PKIs really use emergency
CRLs? 

Regards,
Liaquat

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 11:03:37 +0200
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], Santosh Chokhani <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> Julien:
> 
> I have a problem with the proposal since you can have a "live" mode and
> still some latency in the revocation information as bounded by the next
> Update field.
> 
> An example of such situation is when the responder is not the CA and uses
> the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the
terminology below. I do not see any advantage to use nonces when the
information is backed up by CRLs anyway. Because you know the CRL will
not change until what is indicated in its "nextUpdate" field, sending
a nonce-less OCSP reply should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases,
because they are meant to protect against replay attacks that do not
exist if (i) there is a nextUpdate field (ii) no status change will
occur before the nextUpdate.

Note that if there is a status change before the nextUpdate, then
clients that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate
field, because there is no time frame during which the information may
be cached by the client. And in this case, you need nonces to defend
against replay attacks.
 
> Please note that 2560 does not provide any standard for obtaining
> revocation information.  nextUpdate relates to how the OCSP Responder
> obtains and processes revocation information where as nonce relates to how
> the OCSP Responder produces responses.

Well, the RFC says:

   - nextUpdate: The time at or before which newer information will be
                    available about the status of the certificate

will essentially says "my reply is valid until nextUpdate". (So, why
use nonces here ...)

and 

   If nextUpdate is not set, the responder is indicating that newer
      revocation information is available all the time.

and in this case, nonces are vital, because the message is not
intrinsically protected as were those containing the nextUpdate field.

--
Julien

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of David Engberg
> Sent: Saturday, August 07, 2004 6:09 PM
> Cc: [email-masked]
> Subject: Re: About the Nonce issue in OCSPv1
> 
> 
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in an
> OCSP response may have value for clients, even when a nonce is used.
> For example, even a client who uses nonces to partially mitigate against
> freshness-related attacks may wish to locally cache responses for some
> period of time.  The "nextUpdate" field may give some guidance to the
> client to indicate an upper bound on safe local caching.
> 
> Previous proposals suggested using a new response extension to signal
> cache/live server support.  Overloading the "nextUpdate" field for this
> purpose allows us to avoid adding any new syntactic elements, but a new
> field or extension would permit the continued use of "nextUpdate" in all
> settings.
> 
> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> > Dear PKIX list,
> >
> > I had closely followed the long discussion about OCSP nonce problems
> > that occured on the list around sep to dec 2003, and recently saw in
> > the minutes of the WG meeting that OCSPv1 was to be clarified on that
> > matter.
> >
> > I would like to submit the following to your appreciation.
> > I believe that the following clarification (interpretation ? :)) of
> > RFC2560 solves all nonce/replay attack problems, without modifying the
> > protocol or adding new extensions, and is fairly consistent with
> > existing client and server implementations and hopefully with the
> > spirit of the RFC.
> >
> > Naturally, comments are welcome and you can feel free to do whatever
> > you want with what's below, notably dumping it into oblivion ;)
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> >
> > General
> > -------
> > The CRL approach to revocation checking has two principal drawbacks:
> > the first one is that one needs to download a full CRL in order to
> > check a single certificate and the second is that a CRL does not
> > provide timely information (there is always a time frame during which
> > a revoked certificate is not yet present in the CRL). The OCSP allows
> > to overcome one or both of these drawbacks, depending on the mode in
> > which it is used.
> >
> > An OCSP server can be configured in two different modes: the "caching"
> > mode and the "live" mode. The live mode means that the server has
> > access to up to date information and will always provide it. The
> > caching mode means that the information obtained from the server has a
> > delay with respect to the up to date information.
> >
> > The caching mode overcomes the bandwidth problem associated with CRL,
> > but does not ensure timely information. The live mode solves both
> > problem, but naturally is more computationaly expensive than the
> > caching one. Typically, the caching mode would be used when the source
> > of revocation information are CRLs but could also be used for
> > efficiency reason when timely information is available.
> >
> > A server MUST NOT operate in caching and live mode at the same time.
> >
> > Clarifying requirements for caching OCSP servers
> > -----------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> present.
> >   It should indicate the expiration date of the (cached) information
> > validity.
> > - the nonce extension can (and should) be ignored
> >
> > Clarifying requirement for live OCSP servers
> > --------------------------------------------
> > - the nextUpdate field of all the SingleResponse elements MUST be
> absent,
> >   thus indicating the information is live
> > - live servers MUST support the nonce extension
> >
> > Client behavior
> > ---------------
> > If a client does not care about timely information, but simply wishes
> > to save bandwidth, he MAY send a request without the Nonce extension.
> >
> > However, the behavior that clients SHOULD follow is:
> >
> > 1) Send a request with a Nonce;
> >
> > 2) If the response contains a Nonce, check that the Nonce matches the
> > one sent. If they do not, reject the response, otherwise, the client
> > is ensured to have timely information;
> >
> > 3) If the response does not contain a Nonce, check that all the
> > SingleReponse elements contain a nextUpdate field, if not reject;
> > otherwise, the client knows that the information is not timely but
> > has, for each certificate, the time frame during which this
> > information is deemed valid. Rejection or acceptance can be decided
> > based on a local policy specifying, for example, acceptable time
> > frames.
> >
> > About the replay attacks
> > ------------------------
> > One of the main issue that was raised during the previous discussions
> > was to enable both server modes (Caching and Live) without prior
> > knowledge of the client without more than one network interaction,
> > while preventing replay attacks.
> >
> > Two different mecanisms are in fact in place to prevent replay
> > attacks: the nonces and the nextUpdate field. The nextUpdate field
> > places an upper limit on the time for which replay attacks are
> > possible. However, because they are only used by caching servers, a
> > replay attack would simply provide the same information as the server
> > itself would. If the nextUpdate field is absent, then the server is
> > live and must have included a nonce in its reply to prevent replay
> > attacks with this message.
> >
> > The danger may occurs when a message corresponding to one type of
> > protection is replaced by a replayed message corresponding to the
> > other. But in fact, there is only one configuration in which this may
> > lead to a security risk:
> >
> > - A client sends a nonceless request
> > - An attacker replies with a previously intercepted live response
> >
> > In that case, the client can still check that the producedAt and
> > thisUpdate fields are recent enough to mitigate the attack... At any
> > rate, clients should always send requests with nonce if they want
> > security...
> >

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 10:47:30 +0200
To: David Engberg <[email-masked]>
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], David Engberg <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Aug 07, 2004 at 06:08:37PM -0400, David Engberg wrote:
> 
> Julien -
> 
> Interesting suggestions.  I wonder whether the "nextUpdate" field in an 
> OCSP response may have value for clients, even when a nonce is used. 
> For example, even a client who uses nonces to partially mitigate against 
> freshness-related attacks may wish to locally cache responses for some 
> period of time.  The "nextUpdate" field may give some guidance to the 
> client to indicate an upper bound on safe local caching.

David,

Well, I would tend to think that if a nextUpdate field is present to
indicate a "safe local caching" period, then, a nonce was useless
anyway. As a matter a fact, a "safe local caching" period would tend to
indicate the status of the cert will not be changed until the end of
the period, so why use nonces ?

Nonce only offer additionnal protection for "really live" message,
otherwise the thisUpdate + nextUpdate fields are enough. It works for
CRLs :)

> Previous proposals suggested using a new response extension to signal 
> cache/live server support.  Overloading the "nextUpdate" field for this 
> purpose allows us to avoid adding any new syntactic elements, but a new 
> field or extension would permit the continued use of "nextUpdate" in all 
> settings.

I have naturally read all of them, and I was at first quite convinced by
a "IDoNotSupportNonces" extension, but I then though that the
nextUpdate field might be enough and (maybe) match real-life usage.
The quasi-totality of deployed OCSP responders are "caching" anyway.

--
Julien

> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> >Dear PKIX list,
> >
> >I had closely followed the long discussion about OCSP nonce problems
> >that occured on the list around sep to dec 2003, and recently saw in
> >the minutes of the WG meeting that OCSPv1 was to be clarified on that
> >matter.
> >
> >I would like to submit the following to your appreciation.
> >I believe that the following clarification (interpretation ? :))
> >of RFC2560 solves all nonce/replay attack problems, without modifying
> >the protocol or adding new extensions, and is fairly consistent with
> >existing client and server implementations and hopefully with the
> >spirit of the RFC.
> >
> >Naturally, comments are welcome and you can feel free to do whatever you
> >want with what's below, notably dumping it into oblivion ;)
> >
> >Regards,
> >
> >-- 
> >Julien Stern
> >
> >
> >General
> >-------
> >The CRL approach to revocation checking has two principal drawbacks:
> >the first one is that one needs to download a full CRL in order to
> >check a single certificate and the second is that a CRL does not
> >provide timely information (there is always a time frame during which
> >a revoked certificate is not yet present in the CRL). The OCSP allows
> >to overcome one or both of these drawbacks, depending on the mode in
> >which it is used.
> >
> >An OCSP server can be configured in two different modes: the "caching"
> >mode and the "live" mode. The live mode means that the server has access
> >to up to date information and will always provide it. The caching mode
> >means that the information obtained from the server has a delay with
> >respect to the up to date information.
> >
> >The caching mode overcomes the bandwidth problem associated with CRL,
> >but does not ensure timely information. The live mode solves both
> >problem, but naturally is more computationaly expensive than the caching
> >one. Typically, the caching mode would be used when the source of
> >revocation information are CRLs but could also be used for efficiency
> >reason when timely information is available.
> >
> >A server MUST NOT operate in caching and live mode at the same time.
> >
> >Clarifying requirements for caching OCSP servers
> >-----------------------------------------------
> >- the nextUpdate field of all the SingleResponse elements MUST be present.
> >  It should indicate the expiration date of the (cached) information 
> >validity.
> >- the nonce extension can (and should) be ignored
> >
> >Clarifying requirement for live OCSP servers
> >--------------------------------------------
> >- the nextUpdate field of all the SingleResponse elements MUST be absent,
> >  thus indicating the information is live
> >- live servers MUST support the nonce extension
> >
> >Client behavior
> >---------------
> >If a client does not care about timely information, but simply wishes
> >to save bandwidth, he MAY send a request without the Nonce extension.
> >
> >However, the behavior that clients SHOULD follow is:
> >
> >1) Send a request with a Nonce;
> >
> >2) If the response contains a Nonce, check that the Nonce matches the
> >one sent. If they do not, reject the response, otherwise, the client is
> >ensured to have timely information;
> >
> >3) If the response does not contain a Nonce, check that all the
> >SingleReponse elements contain a nextUpdate field, if not reject;
> >otherwise, the client knows that the information is not timely but has,
> >for each certificate, the time frame during which this information is
> >deemed valid. Rejection or acceptance can be decided based on a local
> >policy specifying, for example, acceptable time frames.
> >
> >About the replay attacks
> >------------------------
> >One of the main issue that was raised during the previous discussions
> >was to enable both server modes (Caching and Live) without prior
> >knowledge of the client without more than one network interaction,
> >while preventing replay attacks.
> >
> >Two different mecanisms are in fact in place to prevent replay attacks:
> >the nonces and the nextUpdate field. The nextUpdate field places an
> >upper limit on the time for which replay attacks are possible. However,
> >because they are only used by caching servers, a replay attack would
> >simply provide the same information as the server itself would. If
> >the nextUpdate field is absent, then the server is live and must have
> >included a nonce in its reply to prevent replay attacks with this
> >message.
> >
> >The danger may occurs when a message corresponding to one type of
> >protection is replaced by a replayed message corresponding to the other.
> >But in fact, there is only one configuration in which this may lead to a
> >security risk:
> >
> >- A client sends a nonceless request
> >- An attacker replies with a previously intercepted live response
> >
> >In that case, the client can still check that the producedAt and
> >thisUpdate fields are recent enough to mitigate the attack... At any
> >rate, clients should always send requests with nonce if they want
> >security...
> >

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Sun, 8 Aug 2004 10:57:25 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0231_01C47D36.7CC5A490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Julien:

I have a problem with the proposal since you can have a "live" mode and
still some latency in the revocation information as bounded by the next
Update field.

An example of such situation is when the responder is not the CA and uses
the CRL as the means of obtaining the revocation information.

Please note that 2560 does not provide any standard for obtaining
revocation information.  nextUpdate relates to how the OCSP Responder
obtains and processes revocation information where as nonce relates to how
the OCSP Responder produces responses.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Saturday, August 07, 2004 6:09 PM
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

Julien -

Interesting suggestions.  I wonder whether the "nextUpdate" field in an
OCSP response may have value for clients, even when a nonce is used.
For example, even a client who uses nonces to partially mitigate against
freshness-related attacks may wish to locally cache responses for some
period of time.  The "nextUpdate" field may give some guidance to the
client to indicate an upper bound on safe local caching.

Previous proposals suggested using a new response extension to signal
cache/live server support.  Overloading the "nextUpdate" field for this
purpose allows us to avoid adding any new syntactic elements, but a new
field or extension would permit the continued use of "nextUpdate" in all
settings.

Thanks,
Dave

Julien Stern wrote:
>
>
> Dear PKIX list,
>
> I had closely followed the long discussion about OCSP nonce problems
> that occured on the list around sep to dec 2003, and recently saw in
> the minutes of the WG meeting that OCSPv1 was to be clarified on that
> matter.
>
> I would like to submit the following to your appreciation.
> I believe that the following clarification (interpretation ? :)) of
> RFC2560 solves all nonce/replay attack problems, without modifying the
> protocol or adding new extensions, and is fairly consistent with
> existing client and server implementations and hopefully with the
> spirit of the RFC.
>
> Naturally, comments are welcome and you can feel free to do whatever
> you want with what's below, notably dumping it into oblivion ;)
>
> Regards,
>
> --
> Julien Stern
>
>
> General
> -------
> The CRL approach to revocation checking has two principal drawbacks:
> the first one is that one needs to download a full CRL in order to
> check a single certificate and the second is that a CRL does not
> provide timely information (there is always a time frame during which
> a revoked certificate is not yet present in the CRL). The OCSP allows
> to overcome one or both of these drawbacks, depending on the mode in
> which it is used.
>
> An OCSP server can be configured in two different modes: the "caching"
> mode and the "live" mode. The live mode means that the server has
> access to up to date information and will always provide it. The
> caching mode means that the information obtained from the server has a
> delay with respect to the up to date information.
>
> The caching mode overcomes the bandwidth problem associated with CRL,
> but does not ensure timely information. The live mode solves both
> problem, but naturally is more computationaly expensive than the
> caching one. Typically, the caching mode would be used when the source
> of revocation information are CRLs but could also be used for
> efficiency reason when timely information is available.
>
> A server MUST NOT operate in caching and live mode at the same time.
>
> Clarifying requirements for caching OCSP servers
> -----------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be
present.
>   It should indicate the expiration date of the (cached) information
> validity.
> - the nonce extension can (and should) be ignored
>
> Clarifying requirement for live OCSP servers
> --------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be
absent,
>   thus indicating the information is live
> - live servers MUST support the nonce extension
>
> Client behavior
> ---------------
> If a client does not care about timely information, but simply wishes
> to save bandwidth, he MAY send a request without the Nonce extension.
>
> However, the behavior that clients SHOULD follow is:
>
> 1) Send a request with a Nonce;
>
> 2) If the response contains a Nonce, check that the Nonce matches the
> one sent. If they do not, reject the response, otherwise, the client
> is ensured to have timely information;
>
> 3) If the response does not contain a Nonce, check that all the
> SingleReponse elements contain a nextUpdate field, if not reject;
> otherwise, the client knows that the information is not timely but
> has, for each certificate, the time frame during which this
> information is deemed valid. Rejection or acceptance can be decided
> based on a local policy specifying, for example, acceptable time
> frames.
>
> About the replay attacks
> ------------------------
> One of the main issue that was raised during the previous discussions
> was to enable both server modes (Caching and Live) without prior
> knowledge of the client without more than one network interaction,
> while preventing replay attacks.
>
> Two different mecanisms are in fact in place to prevent replay
> attacks: the nonces and the nextUpdate field. The nextUpdate field
> places an upper limit on the time for which replay attacks are
> possible. However, because they are only used by caching servers, a
> replay attack would simply provide the same information as the server
> itself would. If the nextUpdate field is absent, then the server is
> live and must have included a nonce in its reply to prevent replay
> attacks with this message.
>
> The danger may occurs when a message corresponding to one type of
> protection is replaced by a replayed message corresponding to the
> other. But in fact, there is only one configuration in which this may
> lead to a security risk:
>
> - A client sends a nonceless request
> - An attacker replies with a previously intercepted live response
>
> In that case, the client can still check that the producedAt and
> thisUpdate fields are recent enough to mitigate the attack... At any
> rate, clients should always send requests with nonce if they want
> security...
>

------=_NextPart_000_0231_01C47D36.7CC5A490
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0231_01C47D36.7CC5A490--

Date: Sat, 07 Aug 2004 18:08:37 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
CC: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050401040707090001020009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julien -

Interesting suggestions.  I wonder whether the "nextUpdate" field in an 
OCSP response may have value for clients, even when a nonce is used. 
For example, even a client who uses nonces to partially mitigate against 
freshness-related attacks may wish to locally cache responses for some 
period of time.  The "nextUpdate" field may give some guidance to the 
client to indicate an upper bound on safe local caching.

Previous proposals suggested using a new response extension to signal 
cache/live server support.  Overloading the "nextUpdate" field for this 
purpose allows us to avoid adding any new syntactic elements, but a new 
field or extension would permit the continued use of "nextUpdate" in all 
settings.

Thanks,
Dave

Julien Stern wrote:
> 
> 
> Dear PKIX list,
> 
> I had closely followed the long discussion about OCSP nonce problems
> that occured on the list around sep to dec 2003, and recently saw in
> the minutes of the WG meeting that OCSPv1 was to be clarified on that
> matter.
> 
> I would like to submit the following to your appreciation.
> I believe that the following clarification (interpretation ? :))
> of RFC2560 solves all nonce/replay attack problems, without modifying
> the protocol or adding new extensions, and is fairly consistent with
> existing client and server implementations and hopefully with the
> spirit of the RFC.
> 
> Naturally, comments are welcome and you can feel free to do whatever you
> want with what's below, notably dumping it into oblivion ;)
> 
> Regards,
> 
> -- 
> Julien Stern
> 
> 
> General
> -------
> The CRL approach to revocation checking has two principal drawbacks:
> the first one is that one needs to download a full CRL in order to
> check a single certificate and the second is that a CRL does not
> provide timely information (there is always a time frame during which
> a revoked certificate is not yet present in the CRL). The OCSP allows
> to overcome one or both of these drawbacks, depending on the mode in
> which it is used.
> 
> An OCSP server can be configured in two different modes: the "caching"
> mode and the "live" mode. The live mode means that the server has access
> to up to date information and will always provide it. The caching mode
> means that the information obtained from the server has a delay with
> respect to the up to date information.
> 
> The caching mode overcomes the bandwidth problem associated with CRL,
> but does not ensure timely information. The live mode solves both
> problem, but naturally is more computationaly expensive than the caching
> one. Typically, the caching mode would be used when the source of
> revocation information are CRLs but could also be used for efficiency
> reason when timely information is available.
> 
> A server MUST NOT operate in caching and live mode at the same time.
> 
> Clarifying requirements for caching OCSP servers
> -----------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be present.
>   It should indicate the expiration date of the (cached) information 
> validity.
> - the nonce extension can (and should) be ignored
> 
> Clarifying requirement for live OCSP servers
> --------------------------------------------
> - the nextUpdate field of all the SingleResponse elements MUST be absent,
>   thus indicating the information is live
> - live servers MUST support the nonce extension
> 
> Client behavior
> ---------------
> If a client does not care about timely information, but simply wishes
> to save bandwidth, he MAY send a request without the Nonce extension.
> 
> However, the behavior that clients SHOULD follow is:
> 
> 1) Send a request with a Nonce;
> 
> 2) If the response contains a Nonce, check that the Nonce matches the
> one sent. If they do not, reject the response, otherwise, the client is
> ensured to have timely information;
> 
> 3) If the response does not contain a Nonce, check that all the
> SingleReponse elements contain a nextUpdate field, if not reject;
> otherwise, the client knows that the information is not timely but has,
> for each certificate, the time frame during which this information is
> deemed valid. Rejection or acceptance can be decided based on a local
> policy specifying, for example, acceptable time frames.
> 
> About the replay attacks
> ------------------------
> One of the main issue that was raised during the previous discussions
> was to enable both server modes (Caching and Live) without prior
> knowledge of the client without more than one network interaction,
> while preventing replay attacks.
> 
> Two different mecanisms are in fact in place to prevent replay attacks:
> the nonces and the nextUpdate field. The nextUpdate field places an
> upper limit on the time for which replay attacks are possible. However,
> because they are only used by caching servers, a replay attack would
> simply provide the same information as the server itself would. If
> the nextUpdate field is absent, then the server is live and must have
> included a nonce in its reply to prevent replay attacks with this
> message.
> 
> The danger may occurs when a message corresponding to one type of
> protection is replaced by a replayed message corresponding to the other.
> But in fact, there is only one configuration in which this may lead to a
> security risk:
> 
> - A client sends a nonceless request
> - An attacker replies with a previously intercepted live response
> 
> In that case, the client can still check that the producedAt and
> thisUpdate fields are recent enough to mitigate the attack... At any
> rate, clients should always send requests with nonce if they want
> security...
> 

--------------ms050401040707090001020009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050401040707090001020009--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Ietf-Pkix@Imc. Org" <[email-masked]>, "Pki4ipsec@Honor. Icsalabs. Com" <[email-masked]>
Subject: OCSP in IKEv2
Date: Sat, 7 Aug 2004 10:21:32 -0700
Importance: Normal
Sender: [email-masked]

All,

The intersection of IPSEC with PKI is of recent interest.  Towards that
dialog, Hannes Tschofenig and I have proposed how OCSP could be used to
deliver certificate status in-band to IKEv2.  We were driven first to
consider the important use case of EAP (i.e. the Road Warrior) but also
considered the Peer-to-Peer case in order to develop a general solution.

This individual submission I-D can be found at:
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

Two new certificate encoding types are proposed:  OCSP Responder Hash
and OCSP Response.  An OCSP Responder Hash is sent in a CERTREQ,
computed as trust anchor hashes are computed but sent in a separate
CERTREQ.  A corresponding OCSP Response is sent back in its own CERT
payload and in the context of the CERT payload carrying the
participant's certificate.  That is, an IKEv2 participant sends both its
cert and that cert's status in separate CERT payloads.

Hannes and I look forward to your comments and debate.  I've
cross-posted due to intersecting interests but please post comments to
the IPSEC list only.

Michael Myers

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: SCVP: Speak now or forever hold your peace...
Date: Fri, 6 Aug 2004 15:57:14 -0700
Importance: Normal
Sender: [email-masked]

Tim,

Regarding SCVP closure, I still feel that the document should
normatively translate 3379's notions of DPD and DPV into SCVP ASN.1.
Doing so will reduce ambiguity down the road.  Think OCSP nonces.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Wednesday, August 04, 2004 5:06 PM
To: [email-masked]
Subject: SCVP: Speak now or forever hold your peace...

Folks,

It is time to get serious and finish up SCVP.  In the slides presented
at our
meeting this morning, the SCVP editors requested a "Definitive and final
list
of all issues from workgroup".  I believe that is a reasonable request.
Let's
do our best to get that list documented ASAP, so that -16 can be our
*last*.

I am requesting that everyone in the WG make time to review SCVP and
document
any issues you find by Friday the 13th.  (I am not setting a deadline
for
terminating discussion - it may take a few days to reach consensus on
the
issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can
be
sent to Trevor directly.  Include SCVP in the subject line regardless!

Thanks,

Tim Polk

From: "Michael Myers" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: RE: About the Nonce issue in OCSPv1
Date: Fri, 6 Aug 2004 15:52:58 -0700
Importance: Normal
Sender: [email-masked]

Julien,

Yes, we will be clarifying 2560 in this regard.  As I said in San Diego,
the text will be "accomodative" of servers unable to respond to nonced
requests.  I am aiming to keep this clarification to a paragraph at
most.  Your text is nonetheless very good input.  I look forward to your
review of the final text when it becomes available.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Julien Stern
Sent: Friday, August 06, 2004 3:35 AM
To: [email-masked]
Subject: About the Nonce issue in OCSPv1

Dear PKIX list,

I had closely followed the long discussion about OCSP nonce problems
that occured on the list around sep to dec 2003, and recently saw in
the minutes of the WG meeting that OCSPv1 was to be clarified on that
matter.

I would like to submit the following to your appreciation.
I believe that the following clarification (interpretation ? :))
of RFC2560 solves all nonce/replay attack problems, without modifying
the protocol or adding new extensions, and is fairly consistent with
existing client and server implementations and hopefully with the
spirit of the RFC.

Naturally, comments are welcome and you can feel free to do whatever you
want with what's below, notably dumping it into oblivion ;)

Regards,

--
Julien Stern

General
-------
The CRL approach to revocation checking has two principal drawbacks:
the first one is that one needs to download a full CRL in order to
check a single certificate and the second is that a CRL does not
provide timely information (there is always a time frame during which
a revoked certificate is not yet present in the CRL). The OCSP allows
to overcome one or both of these drawbacks, depending on the mode in
which it is used.

An OCSP server can be configured in two different modes: the "caching"
mode and the "live" mode. The live mode means that the server has access
to up to date information and will always provide it. The caching mode
means that the information obtained from the server has a delay with
respect to the up to date information.

The caching mode overcomes the bandwidth problem associated with CRL,
but does not ensure timely information. The live mode solves both
problem, but naturally is more computationaly expensive than the caching
one. Typically, the caching mode would be used when the source of
revocation information are CRLs but could also be used for efficiency
reason when timely information is available.

A server MUST NOT operate in caching and live mode at the same time.

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be
present.
  It should indicate the expiration date of the (cached) information
validity.
- the nonce extension can (and should) be ignored

Clarifying requirement for live OCSP servers
--------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be
absent,
  thus indicating the information is live
- live servers MUST support the nonce extension

Client behavior
---------------
If a client does not care about timely information, but simply wishes
to save bandwidth, he MAY send a request without the Nonce extension.

However, the behavior that clients SHOULD follow is:

1) Send a request with a Nonce;

2) If the response contains a Nonce, check that the Nonce matches the
one sent. If they do not, reject the response, otherwise, the client is
ensured to have timely information;

3) If the response does not contain a Nonce, check that all the
SingleReponse elements contain a nextUpdate field, if not reject;
otherwise, the client knows that the information is not timely but has,
for each certificate, the time frame during which this information is
deemed valid. Rejection or acceptance can be decided based on a local
policy specifying, for example, acceptable time frames.

About the replay attacks
------------------------
One of the main issue that was raised during the previous discussions
was to enable both server modes (Caching and Live) without prior
knowledge of the client without more than one network interaction,
while preventing replay attacks.

Two different mecanisms are in fact in place to prevent replay attacks:
the nonces and the nextUpdate field. The nextUpdate field places an
upper limit on the time for which replay attacks are possible. However,
because they are only used by caching servers, a replay attack would
simply provide the same information as the server itself would. If
the nextUpdate field is absent, then the server is live and must have
included a nonce in its reply to prevent replay attacks with this
message.

The danger may occurs when a message corresponding to one type of
protection is replaced by a replayed message corresponding to the other.
But in fact, there is only one configuration in which this may lead to a
security risk:

- A client sends a nonceless request
- An attacker replies with a previously intercepted live response

In that case, the client can still check that the producedAt and
thisUpdate fields are recent enough to mitigate the attack... At any
rate, clients should always send requests with nonce if they want
security...

From: "Julien Stern" <[email-masked]>
Date: Fri, 6 Aug 2004 12:34:48 +0200
To: [email-masked]
Subject: About the Nonce issue in OCSPv1
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Dear PKIX list,

I had closely followed the long discussion about OCSP nonce problems
that occured on the list around sep to dec 2003, and recently saw in
the minutes of the WG meeting that OCSPv1 was to be clarified on that
matter.

I would like to submit the following to your appreciation.
I believe that the following clarification (interpretation ? :))
of RFC2560 solves all nonce/replay attack problems, without modifying
the protocol or adding new extensions, and is fairly consistent with
existing client and server implementations and hopefully with the
spirit of the RFC.

Naturally, comments are welcome and you can feel free to do whatever you
want with what's below, notably dumping it into oblivion ;)

Regards,

--
Julien Stern

General
-------
The CRL approach to revocation checking has two principal drawbacks:
the first one is that one needs to download a full CRL in order to
check a single certificate and the second is that a CRL does not
provide timely information (there is always a time frame during which
a revoked certificate is not yet present in the CRL). The OCSP allows
to overcome one or both of these drawbacks, depending on the mode in
which it is used.

An OCSP server can be configured in two different modes: the "caching"
mode and the "live" mode. The live mode means that the server has access
to up to date information and will always provide it. The caching mode
means that the information obtained from the server has a delay with
respect to the up to date information.

The caching mode overcomes the bandwidth problem associated with CRL,
but does not ensure timely information. The live mode solves both
problem, but naturally is more computationaly expensive than the caching
one. Typically, the caching mode would be used when the source of
revocation information are CRLs but could also be used for efficiency
reason when timely information is available.

A server MUST NOT operate in caching and live mode at the same time.

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be present.
  It should indicate the expiration date of the (cached) information validity.
- the nonce extension can (and should) be ignored

Clarifying requirement for live OCSP servers
--------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be absent,
  thus indicating the information is live
- live servers MUST support the nonce extension

Client behavior
---------------
If a client does not care about timely information, but simply wishes
to save bandwidth, he MAY send a request without the Nonce extension.

However, the behavior that clients SHOULD follow is:

1) Send a request with a Nonce;

2) If the response contains a Nonce, check that the Nonce matches the
one sent. If they do not, reject the response, otherwise, the client is
ensured to have timely information;

3) If the response does not contain a Nonce, check that all the
SingleReponse elements contain a nextUpdate field, if not reject;
otherwise, the client knows that the information is not timely but has,
for each certificate, the time frame during which this information is
deemed valid. Rejection or acceptance can be decided based on a local
policy specifying, for example, acceptable time frames.

About the replay attacks
------------------------
One of the main issue that was raised during the previous discussions
was to enable both server modes (Caching and Live) without prior
knowledge of the client without more than one network interaction,
while preventing replay attacks.

Two different mecanisms are in fact in place to prevent replay attacks:
the nonces and the nextUpdate field. The nextUpdate field places an
upper limit on the time for which replay attacks are possible. However,
because they are only used by caching servers, a replay attack would
simply provide the same information as the server itself would. If
the nextUpdate field is absent, then the server is live and must have
included a nonce in its reply to prevent replay attacks with this
message.

The danger may occurs when a message corresponding to one type of
protection is replaced by a replayed message corresponding to the other.
But in fact, there is only one configuration in which this may lead to a
security risk:

- A client sends a nonceless request
- An attacker replies with a previously intercepted live response

In that case, the client can still check that the producedAt and
thisUpdate fields are recent enough to mitigate the attack... At any
rate, clients should always send requests with nonce if they want
security...

Date: Thu,  5 Aug 2004 16:34:37 -0400
From: [email-masked]
To: Francis Dupont <[email-masked]>
Cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace...
Sender: [email-masked]

Francis,

I am sorry some previous comments appeared to be overlooked.  I appreciate 
your resubmitting those so we can build a complete issues list.

BTW, I certainly consider issues like MIME types to be important issues, 
rather than nits.  These issues could adversely affect interoperability, and 
should be noted on list.  Typos, etc. are things best sent straight to the 
editors, since they may become OBE based on other edits.

Thanks,

Tim

Quoting Francis Dupont <[email-masked]>:

>  In your previous mail you wrote:
> 
>    It is time to get serious and finish up SCVP...
> 
> => I had many comments about the previous draft but unfortunately some
> are still valid. As an example of nits the application MIME types changed
> but not everywhere so there are still both application/cv-request and
> application/scvp-request in the document. I'll try to make all comments
> before the dead-line and in the list (as previous comments sent in private
> seemed to have been ignored).
> 
> Regards
> 
> [email-masked]
> 
> PS: I'd like to perform all the certificate validation needed by an IKE
> server in a SCVP responder. I used a partial implementation of SCVP
> in OpenSSL and for the IKE daemon racoon, both on FreeBSD and Linux.
> 
> 
> 

Date: Thu,  5 Aug 2004 13:02:18 -0400
From: [email-masked]
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace...
Sender: [email-masked]

Denis,

I certainly am counting your nine concerns and Peter's four comments as 
unresolved issues.  I understand that deadline will be hard for some people to 
meet, and am sorry that you are one of that group.  As you have commented 
extensively in the past, I am hopeful that 99% of your concerns have already 
been raised.

You may have noticed that I requested (begged?) that issues be raised by the 
deadline, but didn't absolutely forbid posting new issues after that date.  We 
are a security WG, and if security issues are identified on August 14 we will 
have to address them.  (However, late submissions may be ignored if they do 
not fall into that category.)

I hope everyone will treat this as a hard deadline, though.  Establishing a 
complete list is more than a courtesy to the editors of SCVP.  It is a 
necessary step towards completion and progression of SCVP.  The status of SCVP 
has become a major impediment to the development and deployment of products.  
This deadline is a necessary evil.

With respect to the two issues highlighted below:
(1) Your major concern (referencing a single OID in the request) is well 
understood, and has already prompted a lot of discussion.  I expect we can 
handle this one in your absence.  
(2) I believe we can clarify the DPD - DPV split quite easily.  Restructuring 
the document is not necessary, though, and would introduce unacceptable delays.

Have a nice vacation.

Tim

Quoting Denis Pinkas <[email-masked]>:

> Tim,
> 
> I am leaving for holidays tonight, so your message reached me just in time 
> to tell you that I will have not have the time to send more comments before 
> the deadline of Friday 13.
> 
> I may simply say that in general the answers from Trevor have not correctly 
> answered to the nine concerns I raised on July 28.
> 
> The major concern remains to ability to refence only one OID for the 
> validation policy and leave ALL the complexity of client-defined parameters 
> for a validation policy or a validation algorithm (whatever name is being 
> used) as an OPTIONAL feature that DOES not have to be supported by
> implementers.
> 
> I am also supportive of a much cleaner separation between CVP and DPD as 
> advocated by Mike. Even if there are similarities, the two protocols are 
> differents. Some restructuring of the document will be necessary so that 
> this goal can be achieved.
> 
> The comments from Peter should not be forgotten.
> 
> As mentionned by Steve, the S from SCVP is still supposed to mean Simple.
> 
> Denis
> 
> 
> > Folks,
> > 
> > It is time to get serious and finish up SCVP.  In the slides presented at
> our 
> > meeting this morning, the SCVP editors requested a "Definitive and final
> list 
> > of all issues from workgroup".  I believe that is a reasonable request. 
> Let's 
> > do our best to get that list documented ASAP, so that -16 can be our
> *last*.
> > 
> > I am requesting that everyone in the WG make time to review SCVP and
> document 
> > any issues you find by Friday the 13th.  (I am not setting a deadline for 
> > terminating discussion - it may take a few days to reach consensus on the 
> > issue list.  I am just trying to surface all the issues ASAP.)  Once the
> issue 
> > list is stable, I am sure we can work out solutions.
> > 
> > Please post all technical comments to the list.  Editorial comments can be
> 
> > sent to Trevor directly.  Include SCVP in the subject line regardless! 
> > 
> > Thanks,
> > 
> > Tim Polk  
> > 
> 
> 
> 
> 
> 

Date: Thu, 05 Aug 2004 17:36:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace...
Sender: [email-masked]

Tim,

I am leaving for holidays tonight, so your message reached me just in time 
to tell you that I will have not have the time to send more comments before 
the deadline of Friday 13.

I may simply say that in general the answers from Trevor have not correctly 
answered to the nine concerns I raised on July 28.

The major concern remains to ability to refence only one OID for the 
validation policy and leave ALL the complexity of client-defined parameters 
for a validation policy or a validation algorithm (whatever name is being 
used) as an OPTIONAL feature that DOES not have to be supported by implementers.

I am also supportive of a much cleaner separation between CVP and DPD as 
advocated by Mike. Even if there are similarities, the two protocols are 
differents. Some restructuring of the document will be necessary so that 
this goal can be achieved.

The comments from Peter should not be forgotten.

As mentionned by Steve, the S from SCVP is still supposed to mean Simple.

Denis

> Folks,
> 
> It is time to get serious and finish up SCVP.  In the slides presented at our 
> meeting this morning, the SCVP editors requested a "Definitive and final list 
> of all issues from workgroup".  I believe that is a reasonable request.  Let's 
> do our best to get that list documented ASAP, so that -16 can be our *last*.
> 
> I am requesting that everyone in the WG make time to review SCVP and document 
> any issues you find by Friday the 13th.  (I am not setting a deadline for 
> terminating discussion - it may take a few days to reach consensus on the 
> issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
> list is stable, I am sure we can work out solutions.
> 
> Please post all technical comments to the list.  Editorial comments can be 
> sent to Trevor directly.  Include SCVP in the subject line regardless! 
> 
> Thanks,
> 
> Tim Polk  
> 

From: Francis Dupont <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: SCVP: Speak now or forever hold your peace... 
Date: Thu, 05 Aug 2004 04:57:18 +0200
Sender: [email-masked]

 In your previous mail you wrote:

   It is time to get serious and finish up SCVP...

=> I had many comments about the previous draft but unfortunately some
are still valid. As an example of nits the application MIME types changed
but not everywhere so there are still both application/cv-request and
application/scvp-request in the document. I'll try to make all comments
before the dead-line and in the list (as previous comments sent in private
seemed to have been ignored).

Regards

[email-masked]

PS: I'd like to perform all the certificate validation needed by an IKE
server in a SCVP responder. I used a partial implementation of SCVP
in OpenSSL and for the IKE daemon racoon, both on FreeBSD and Linux.

Date: Wed,  4 Aug 2004 20:06:11 -0400
From: [email-masked]
To: [email-masked]
Subject: SCVP: Speak now or forever hold your peace...
Sender: [email-masked]

Folks,

It is time to get serious and finish up SCVP.  In the slides presented at our 
meeting this morning, the SCVP editors requested a "Definitive and final list 
of all issues from workgroup".  I believe that is a reasonable request.  Let's 
do our best to get that list documented ASAP, so that -16 can be our *last*.

I am requesting that everyone in the WG make time to review SCVP and document 
any issues you find by Friday the 13th.  (I am not setting a deadline for 
terminating discussion - it may take a few days to reach consensus on the 
issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can be 
sent to Trevor directly.  Include SCVP in the subject line regardless! 

Thanks,

Tim Polk  

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>
Cc: "IETF-PKIX" <[email-masked]>
Subject: 
Date: Wed, 4 Aug 2004 14:27:23 -0700
Sender: [email-masked]

ASN.1 Errors

1.  General names is in the rfc3280 implicit not explicit.

2.  Line Missing comma following optional for producedAt and queryExtensions

3.  NameValidationAlg - fields are to be lower case names

4.  SCVPStatusCode - values have upper case names not lower case names

5.  fullRequestRefUnsupported has a } not a ) on the value of 51

6.  ValPolicy.isCA is uppercased needs to be lower cased

7.  PoliciesResponse.defaultPolicyID is upper cased - needs to be lower case

8.  ResponseTypes fields need hyphenation

9.  SubjectPublicKeyInfo is imported but never referenced

Jim

Date: Wed, 4 Aug 2004 14:04:58 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes for review & comment by 8-20
Sender: [email-masked]

PKIX WG Meeting 8-4-04

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>

The PKIX WG met once during the 60th IETF. A total of approximately 
73 individuals participated in the meeting.

WG Status and Direction

Document Status Review [Tim Polk (NIST)]

The working group has a number of Internet-Drafts.  Many documents 
are with the ADs or in various stages of WG Last Call. Several others 
are ready for Last Call. (Also, The working group milestones have 
been out of date, although several were recently updated. An 
additional pass to revise the milestones will be made by the WG 
chairs, and the results posted to the WG home page. (slides)

PKIX WG Specifications

LDAP Specifications

PKIX has a number of LDAP-based specifications supporting publication 
and distribution of certificates and CRLs.

LDAP Schemas, String Values, etc. - David Chadwick (U. of Salford)

  draft-ietf-pkix-ldap-crl-schema-02.txt
  draft-ietf-pkix-ldap-ac-schema-01.txt

The WG has a suite of LDAP-PKIX drafts forming a comprehensive 
solution for LDAP based PKI information distribution.  New drafts of 
two I-Ds have been submitted since IETF 59 and additional drafts will 
be published soon after this meeting. Documents will be 
Informational, WG submissions, having previously been individual 
submissions. A late September WG last call is planned, to accommodate 
the author's schedule. (slides)

Practical Considerations for Use of LDAP in PKIX - Kurt Zeilenga 
(LDAPbis WG co-chair)

        Practical considerations must be considered to maximize the 
utility and interoperability of LDAP-based PKIs. This presentation 
discussed known issues and (where applicable) ways to address them. 
Highlights include ";binary" support. Goal is to complete this work 
(3 documents) via staged WG last calls in late August, September, and 
October, so that all 3 are done before D.C. UETF meeting. (slides)

Matching Text Strings in PKIX Certificates - Paul Hoffman (IMC) & 
Steve Hanna (Sun->Funky)

  draft-hoffman-pkix-stringmatch-00.txt

        This specification describes the use of (LDAP) Stringprep to 
support comparison and matching of international text strings.  This 
document resolves an open issue from RFC 3280, where the minimum 
requirements for name comparison were specified as binary matching. 
Since the publication of RFC 3280, the Stringprep specification has 
been completed, providing a solid basis for comparison and matching 
of test strings in PKIX certificates. Target is a standards track 
document as a PKIX WG item, to be referenced from 3280bis. X.500 
provides per-attribute matching rules, and is being updated to use 
Stringprep, so the emphasis in PKIX should be on alternative name 
matching. Target is to identify, and resolve, issues by the next IETF 
meeting. (slides)

RFC 3280 Progression- Tim Polk (NIST)

        NIST will present the current plan and milestones for 
progression of RFC 3280 to Draft Standard. Russ identified a problem 
for 3280bis, related to international string matching, i.e., 3280 
punted on the topic of wildcard matching, and so 3280bis needs to 
address this issue, in the Stringprep context. (slides)

Subject Identification Method - Tim Polk (NIST) for Jongwook Park (KISA)

  draft-ietf-pkix-sim-03.txt

        A new draft of the Subject Identification Method has been 
submitted since IETF 59.  The document is relatively stable and 
mature.  WG Last Call is expected very soon for the next (final?) 
draft of this document. (slides)

SCVP Progression - Tim Polk (NIST) for Trevor Freeman (Microsoft)

  draft-ietf-pkix-scvp-15.txt

        This document has been in WG Last Call since early 2004. 
Completion of WG Last Call was blocked by newly identified 
implementation requirements for unsigned messages to support DPD. 
Early proposals did not satisfy RFC 3739, and were rejected.  A new 
draft has been submitted since IETF 59 implementing unsigned messages 
while satisfying RFC 3379 and the implementation requirements. It 
seems likely that there additional revisions will be needed before 
the document is finished, given last call comments. Target is to be 
done before D.C. meeting. (slides)

OCSPv1 Progression to DRAFT - Mike Myers (Traceroute)
	 Need to resolve an ambiguity in the text, re nonces, to 
clarify this in a fashion that accommodates existing implementation 
practice. Should me a 1 paragraph change and allow the document to 
proceed to DRAFT quickly. (no slides)

Related Specifications & Liaison Presentations

Specification of OCSP in IKEv2 - Mike Myers (TraceRoute)

  draft-myers-ipsec-ikev2-oscp-00.txt

This is an IPsec topic that uses a PKIX protocol. The presentation 
described issues with the specification of OCSP in IKEv2, to provide 
an alternative to sending CRLs via IKE. Motivations are to avoid 
fragmentation concerns in IKE, and because it might be hard to gain 
access to an OCSP server w/o secure access (a chicken & egg problem). 
An individual submission; not a PKIX document. (slides)

User Interface Requirement for the Internet X.509 Public Key 
Infrastructure - Jaehoo Yoon (KISA)

  draft-choi-pkix-ui-00.txt

This document proposes basic requirements for a user interface for 
PKI client software, with an emphasis on usability and smart card 
support. Requirements addressed by the document include root CA 
certificate management, certificate sharing among applications, local 
storage, etc. Targeted to be an informational document for system 
designers. An individual (not PKIX) submission. (slides)

Content-class: urn:content-classes:message
Subject: RE: PKIX WG Agenda for 60th IETF (second try!)
Date: Tue, 3 Aug 2004 23:46:38 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Peter,
Sorry I missed this but as Tim said, I am on vacation and not attending
San Diego so have not been reading every posting. If you had also sent
this mail to me personally you would have at least found out I am on
vacation. Dennis changed the subject line to include SCVP which caught
my attention and since I did not find another posting with the same
subject I wrongly assumed he had forwarded a private mail to the list.
My apologies. 

I will therefore repost my comments directly to you.

Trevor
* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Peter Sylvester
* Sent: Wednesday, July 28, 2004 5:33 AM
* To: [email-masked]
* Cc: [email-masked]
* Subject: Re: PKIX WG Agenda for 60th IETF (second try!)
* 
* 
* 
* it seems to me that some of the results of discussions between
* the editor and me have been forgotten or so.
* 
* 
* I still think that the scvp is not conformant to RFC 3379
* and/or the editors has not done something as announced.
* 
* 1) RFC 3379 says:
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
*    ==> no provision (as far as I see).

[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response or a DPV response from another SCVP
server as an input, however if such as algorithm were to be defined,
then the extension mechanisms within SCVP would permit TSA responses or
DPV responses to be also returned. 

Also which discussing the client requesting the validation information
by value in section 3.2.5 states

"include by value in the CVResponse  every aspect of the validation
policy"

* 
* 
* 2) RFC 3379 says:
*    When the DPV request is authenticated, the client SHOULD be able to
*    include a client identifier in the request for the DPV server to
copy
*    into the response.  Mechanisms for matching this identifier with
the
*    authenticated identity depends on local DPV server conditions
and/or
*    the validation policy.  The DPV server MAY choose to blindly copy
the
*    identifier, omit the identifier, or return an error response.
* 
* The current text is SCVP says:
* 
*   The OPTIONAL requestor item is used to identify the requestor.  The
*   value is only of local significance to the requestor.  If the SCVP
*   client includes a requestor value in the request, then the SCVP
*   server MUST return the same value if the server is generating a
*   specific response.
* 
* 
* tf also said:
* 
* > Given there are plenty of ways a client can generate a "unique" as
well
* > as other behaviors like it can encode a DN in the octet sting if it
* > likes I don't see a problem. Its down to the client to do what it
thinks
* > fit. The value is simply replayed by the server so it is treated a
* > binary blob.
* 
[TF] Since you had not linked our discussion on the requestor field to
this section of 3379 before we have been at cross purposes. As Dennis
pointed out this field is intended for SCVP relay so the current text is
accurate for that purpose. It's a opaque blob to the server so
definition of any standard structures in this case was and is a
pointless exercise.

It is also not appropriate to reuse the requestor field because of the
case of authenticated relay. Since the client signed the request with a
certificate in this case, the request complies with 3379. We just need
to add a GeneralName field in the response for this purpose. Though
remember that with cached responses this will not be possible.

.
* There is nothing else possible for the server except copying, or,
* no mechanisms to match this with the some authenticated entity
* can be safely developped if it is solely 'up to the client to encode
* whatever'.
* 
* I had proposed two changes to the logic of 0 terminated octet strings
by:
* 
* - a sequence of octet strings allowing a real opaque string.
* - a choice of generalname
* 
* I.e.
* 
*    Identifiers ::= SEQUENCE OF {
*           CHOICE {
*                opaqueId OCTET STRING,
*                nameId GeneralName
*           }
* 
* No comment to this proposition as far as I remember.
* 
* 3) In May 204 trevor wrote:
* 
* > I think we can use the Cert sign bit in key usage so the is CA bit
can
* > be removed from SCVP15
* 
* which was not done.

[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4, k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.

* 
* 4) Somewhat related to this, and to the provisions to search in DPD or
* validate
*    in DPV several types of extensions, I had proposed to opetionally
* search
*    for the pathlength basicconstraint. if for example a client has a
*    cert and a CA cert then one could use it to search only for CAs
that
*    have at least a pathlength of 1.
* 
* 
* I seem to understand that the rule in this WG is:
* 
* - editor, chairmen, iesg says something ==> accepted if no response
* - others ==> rejected if no response from anyone.
* 
* all totally independant of the content of the comment.
* 
* At least point 3 doesn't fit into this rule.
* 
* I'd like to to see whether there is someone participating
* in this list who agrees with something or considers it as useful ...
* 
* Thanks for consideration
* Peter
* 
* 

Date: Tue,  3 Aug 2004 20:50:37 -0400
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Final Agenda for PKIX session
Sender: [email-masked]

Here is the final agenda for the PKIX session at the 60th IETF.

Changes:
(1) I will present the SIM draft and the SCVP discussion, as the lead authors
are unavailable.
(2) The URL for the Internet Draft associated with Mike Myers' presentation
has been specified.
(3) Jaehoo Yoon will present the user interface draft.

Thanks,

Tim Polk

---------------------------------------------

PKIX WG (pkix-wg)

Wednesday August 4, 2004 0900-1130
=================================

CHAIR: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

AGENDA:

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

        The working group has a number of Internet-Drafts.  Many
        documents are with the ADs or in various stages of WG Last Call.
        Several others are ready for Last Call. (10 min.)

1.2 Proposed WG Milestones [Tim Polk (NIST)]

        The working group milestones are out of date.  New milestones are
        needed; these milestones need to satisfy IESG direction for an orderly
        closeout of WG activities. (10 min.)

2. PKIX WG Specifications

2.1 LDAP Specifications

       The PKIX WG has a number of LDAP-based specifications supporting
       publication and distribution of certificates and CRLs.

2.1 LDAP Schemas, String Values, and more
       - David Chadwick (U. of Salford)

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-02.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-01.txt

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts of two I-Ds
       have been submitted since IETF 59; additional drafts will be published
       soon after this meeting; the presenter will discuss the changes in the
       and highlight issues that must be resolved before Last Call.  (15 min.)

2.2 Practical Considerations for Use of LDAP in PKIX
       - Kurt Zeilenga (LDAPbis WG co-chair)

   (no draft)

       Practical considerations must be considered to maximize the utility
       and interoperability of LDAP-based PKIs.  This presentation will
       highlight known issues and (where applicable) ways to address them.
       (10 min.)

2.3 Matching Text Strings in PKIX Certificates
       - Paul Hoffman (IMC) and Steve Hanna (Sun)

   http://www.ietf.org/internet-drafts/draft-hoffman-pkix-stringmatch-00.txt

       This specification describes the use of Stringprep to support comparison
       and matching of international text strings.  This document resolves 
       an open issue from RFC 3280, where the minimum requirements for name 
       comparison were specified as binary matching.  Since the publication of 
       RFC 3280, the stringprep specification has been completed, providing a
       solid basis for comparison and matching of test strings in PKIX
       certificates. (15 min.)

[see also

   http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-strprep-04.txt]

2.4 RFC 3280 Progression
       - Tim Polk (NIST)

   (no draft)

       NIST will present the current plan and milestones for progression of
       RFC 3280 to Draft Standard.   (5 min.)

2.5 Subject Identification Method
       - Tim Polk

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-03.txt

       A new draft of the Subject Identification Method has been submitted 
since
       IETF 59.  The document is relatively stable and mature.  WG Last Call is
       expected for the next draft of this document. (15 min.)

2.6 SCVP Progression
       - Tim Polk

http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-15.txt

       This document has been in WG Last Call since early 2004.  Completion 
       of WG Last Call was blocked by newly identified implementation
       requirements for unsigned messages to support DPD.  Early proposals
       did not satisfy RFC 3739, and were rejected.  A new draft has been
       submitted since IETF 59 implementing unsigned messgaes while satisfying
       RFC 3379 and the implementation requirements. (5 min.)

3. Related Specifications & Liaison Presentations

       Time allowing, liaison presentations will be accommodated to ensure the
       PKIX WG is aware of related specifications currently progressing as 
       individual drafts.

3.1 Specification of OCSP in IKEv2
        - Mike Myers (TraceRoute)

   http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

        This presentation will highlight issues with the specification of OCSP
        in IKEv2. (10 min.)

3.2 User Interface Requirement for the Internet X.509 Public Key Infrastructure
        - Jaehoo Yoon (KISA)

   http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-00.txt

        This document provides basic requirements of user interface at PKI
        client software that satisfy a full of PKI implementation with
        usability. To meet with the requirements, it defines root CA
        certificate trust mechanism, certificate sharing mechanism, and 
        certificate representation method. (10 min.)

Date: Mon,  2 Aug 2004 16:37:13 -0400
From: [email-masked]
To: Peter Sylvester <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on SCVP15
Sender: [email-masked]

Peter,

Quoting Peter Sylvester <[email-masked]>:
> Note again, that Trevor answers Denis, not to my comments, 
> I may be on his black list. 

It is far more likely that Trevor did not read your message because the 
subject line indicated it was a comment on the PKIX agenda.

As Trevor is on vacation, and will not be in San Diego, comments on the agenda 
probably seem immaterial.

I have forwarded the message to Trevor with a more concise subject line...

Tim

Date: Mon,  2 Aug 2004 15:51:18 -0400
From: [email-masked]
To: Peter Sylvester <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on SCVP15
Sender: [email-masked]

Peter,

In your last email you stated:

Quoting Peter Sylvester <[email-masked]>:
> Since last call, many changes had been added without any discussion, 
> i.e. all the extensions stuff, these are clearly new features, and 
> not just editorial or bug corrections. 
> 
> I think that all extensions which are features and not
> completions should be properly discussed and developed
> or removed.
> 
> Peter
> 

Please note that a "design team" was formed at my request to bring the whole 
unsigned DPD issue to resolution.  I was hoping that the design team would be 
more efficient in finding a soilution than the on-list discussion.  So, if the 
changes you refer to involve unsigned DPD, it is *entirely* appropriate for 
these features to be included in the new draft.  

To quote RFC 2418:

> 6.5. Design teams

>    It is often useful, and perhaps inevitable, for a sub-group of a
>    working group to develop a proposal to solve a particular problem.
>    Such a sub-group is called a design team.  In order for a design team
>    to remain small and agile, it is acceptable to have closed membership
>    and private meetings.  Design teams may range from an informal chat
>    between people in a hallway to a formal set of expert volunteers that
>    the WG chair or AD appoints to attack a controversial problem.  The
>    output of a design team is always subject to approval, rejection or
>    modification by the WG as a whole.

Please note the final sentence: the WG still gets the final say, not the 
design team!

Thanks,

Tim Polk

From: "Michael Myers" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
Subject: RE: SCVP-15
Date: Mon, 2 Aug 2004 07:47:48 -0700
Importance: Normal
Sender: [email-masked]

I fully agree with your first point.  3379 is the defining document on
the concepts of DPD and DPV.  That's why we worked so hard on it.  But
my point is that, as with other 3379 text, those concepts need
translation into an implementable protocol.  Thus, for example, any SCVP
request containing any of the <validated path> certCheck or wantBack
values is, by definition, NOT a DPD request.  I think we need crisp,
normative definitions in this instance along the lines I proposed in
order to ensure security in implementations and interoperability among
them.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Trevor Freeman
Sent: Monday, August 02, 2004 12:05 AM
To: Michael Myers; [email-masked]
Subject: RE: SCVP-15

Hi Mike,
I think the definitions in 3379 are more accurate since it is what the
client does with the response which is litmus test between DPD and DPV.
I am happy to add test along the lines you suggest as illustrations of
what a DPD client might do.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[email-masked]]
* Sent: Saturday, July 31, 2004 8:08 AM
* To: Trevor Freeman; [email-masked]
* Subject: RE: SCVP-15
*
* 3379's definitions work well for 3379, but I think the document should
* say that with respect to 3379, "DPD" in this document (i.e. SCVP)
means
* a request where:
*
* 1. certChecks contains at most id-stc-build-pkc-path; AND
*
* 2. wantBack contains at most either one or both of
*    {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.
*
* while "DPV" means a request that includes any of the other values
* defined for use in these two elements.
*
* Mike
*
* -----Original Message-----
* From: [email-masked]
* [mailto:[email-masked]]On Behalf Of Trevor Freeman
* Sent: Friday, July 30, 2004 10:38 PM
* To: Michael Myers; [email-masked]
* Subject: RE: SCVP-15
*
*
*
* Hi Mike,
* Sorry for the slow response but I am on vacation so am not reading
mail
* as frequently as normal. I agree with your point on needing clear
* definitions for DPD and DPV but I think the ones provided in 3379 are
* adequate. That would simply require adding references to sections 2
and
* 3 of the RFC.
*
* Do you agree?
* Trevor
*
* * -----Original Message-----
* * From: [email-masked]
* [mailto:[email-masked]]
* * On Behalf Of Michael Myers
* * Sent: Thursday, July 22, 2004 11:43 AM
* * To: [email-masked]
* * Subject: Re: SCVP-15
* *
* *
* * Trevor,
* *
* * Section 3.2.10, extracted below, is a good step forward to closure
on
* * the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* * comfortable with its default to TRUE.
* *
* * The second paragraph however needs an implementable definition of
DPD
* * vice DPV with respect to SCVP ASN.1 in order to assert that that a
* * request is in error if it asks for a validation assertion in the
* context
* * of signResponse set to FALSE.
* *
* * Mike
* *
* *
* *
* *
* * 3.2.10 signResponse
* *
* *   The signResponse specifies if the client requires the server to
* *   sign a response to the validation request. If the client is
* *   performing full chain validation on the response and it is not
* *   concerned about the authenticity of the source of the data, then
* *   the client does not benefit from the signature on the response in
* *   which case it can indicate to the server that the signature is
* *   unnecessary via the signResponse value.
* *
* *   SCVP clients that support DPD MUST support setting this value to
* *   FALSE. Since DPV responses must be signed, DPV only SCVP clients
* *   MUST NOT to support this value. SCVP servers SHOULD support
* *   returning unsigned responses. It is a local policy decision on the
* *   part of the server to return signed or unsigned responses if this
* *   value is set to FALSE.
* *
*
*
*

Date: Mon, 02 Aug 2004 15:36:11 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: Comments on SCVP15
Sender: [email-masked]

Trevor,

Would you please also respond to Peter ?
Peter is correct when saying that major changes have been made.

>>Hi Denis,
>>The concern you express here is touching.

I have some difficulties to understand the meaning of this sentence.

I certainly missed some or all of the e-mails you sent explaining the 
differences between the successive versions of SCVP, or/and the section at 
the very end of the document that would be there to keep track of the 
changes until the document is published. :-(

Going back to technical concerns, we still have a major disagreement about 
the concept and the use of a validation policy.

RFC 3379 states:

    it is expected that most clients will simply reference a validation
    policy for a given application or accept the DPV server's default
    validation policy.

Referencing a validation policy does not require to define any parameter, 
hence why all validation policy parameters should be removed from the "first 
level" of the parameters from the SCVP request" and be placed under the OID 
of a "parametrable" validation policy. This is not stylistic.

RFC 3379 states:

    A validation policy is a set of rules against which the validation of
    the certificate is performed.

    A validation policy MAY include several trust anchors.  A trust
    anchor is defined as one public key, a CA name, and a validity time
    interval; a trust anchor optionally includes additional constraints.
    The use of a self-signed certificate is one way to specify the public
    key to be used, the issuer name, and the validity period of the
    public key.

    Additional constraints for each trust anchor MAY be defined.  These
    constraints might include a set of certification policy constraints
    or a set of naming constraints.  These constraints MAY also be
    included in self-signed certificates.

    Additional conditions that apply to the certificates in the path MAY
    also be specified in the validation policy.  For example, specific
    values could be provided for the inputs to the certification path
    validation algorithm in [PKIX-1], such as user-initial-policy-set,
    initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
    any-policy-inhibit.

    Additional conditions that apply to the end-entity certificate MAY
    also be specified in the validation policy.  For example, a specific
    name form might be required.

I believe that our disagrement comes from the fact that you restict a 
validation policy to be only a certification path check done according to 
RFC 3280 section 6, while it may be much more than that: see above.

Denis

PS. I have no time available today to respond to your detailed response to 
my comments. I will try to do it later.

>>See answers below.
>>Trevor
>>
> 
> 
> I am not sure to whom Trevor is talking in the following. 
> Since the original message was from me, and Trevor did not
> answer, Denis, would be be so glad to comment again
> or/and to remind him that he is trying to respond to
> my message. 
> 
> Note again, that Trevor answers Denis, not to my comments, 
> I may be on his black list. 
> 
> 
>>* 
>>* Now awaiting SCVP-16 ... or much better, before issuing it, a response
>>to
>>* the many technical comments raised on this mailing list on SCVP-15.
>>
>>[TF] A reply to you last posting has been made. What is of concern is
>>the fact that you requested changes in your posting on SCVP15 to
>>sections of SCVP which have been stable for the past 15 versions. I will
>>only post draft 16 when I have a definitive and final set of issues from
>>you and there will only be editorial changes from then on. This point is
>>not negotiable. Anything else will have to wait. 
> 
> 
> Trevor, are you assuming that people haven't archived
> the previous 15 versions? configID, policyID had changed
> and this was a little bit more than a textual change IMO.
> Furthermore, the resulting texts were sometimes uncomprehensible
> since the asn1 syntaxes were inconsistent or unimplementable. 
> 
> Since last call, many changes had been added without any discussion, 
> i.e. all the extensions stuff, these are clearly new features, and 
> not just editorial or bug corrections. 
> 
> I think that all extensions which are features and not
> completions should be properly discussed and developed
> or removed.
> 
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Date: Mon, 2 Aug 2004 15:06:10 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on SCVP15
Cc: [email-masked]
Sender: [email-masked]

> Hi Denis,
> The concern you express here is touching.
> See answers below.
> Trevor
> 

I am not sure to whom Trevor is talking in the following. 
Since the original message was from me, and Trevor did not
answer, Denis, would be be so glad to comment again
or/and to remind him that he is trying to respond to
my message. 

Note again, that Trevor answers Denis, not to my comments, 
I may be on his black list. 

> * 
> * Now awaiting SCVP-16 ... or much better, before issuing it, a response
> to
> * the many technical comments raised on this mailing list on SCVP-15.
> 
> [TF] A reply to you last posting has been made. What is of concern is
> the fact that you requested changes in your posting on SCVP15 to
> sections of SCVP which have been stable for the past 15 versions. I will
> only post draft 16 when I have a definitive and final set of issues from
> you and there will only be editorial changes from then on. This point is
> not negotiable. Anything else will have to wait. 

Trevor, are you assuming that people haven't archived
the previous 15 versions? configID, policyID had changed
and this was a little bit more than a textual change IMO.
Furthermore, the resulting texts were sometimes uncomprehensible
since the asn1 syntaxes were inconsistent or unimplementable. 

Since last call, many changes had been added without any discussion, 
i.e. all the extensions stuff, these are clearly new features, and 
not just editorial or bug corrections. 

I think that all extensions which are features and not
completions should be properly discussed and developed
or removed.

Peter

Content-class: urn:content-classes:message
Subject: RE: SCVP-15
Date: Mon, 2 Aug 2004 00:05:26 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Mike,
I think the definitions in 3379 are more accurate since it is what the
client does with the response which is litmus test between DPD and DPV.
I am happy to add test along the lines you suggest as illustrations of
what a DPD client might do.

Trevor

* -----Original Message-----
* From: Michael Myers [mailto:[email-masked]]
* Sent: Saturday, July 31, 2004 8:08 AM
* To: Trevor Freeman; [email-masked]
* Subject: RE: SCVP-15
* 
* 3379's definitions work well for 3379, but I think the document should
* say that with respect to 3379, "DPD" in this document (i.e. SCVP)
means
* a request where:
* 
* 1. certChecks contains at most id-stc-build-pkc-path; AND
* 
* 2. wantBack contains at most either one or both of
*    {id-swb-pkc-cert-path, id-swb-pkc-revocation-info}.
* 
* while "DPV" means a request that includes any of the other values
* defined for use in these two elements.
* 
* Mike
* 
* -----Original Message-----
* From: [email-masked]
* [mailto:[email-masked]]On Behalf Of Trevor Freeman
* Sent: Friday, July 30, 2004 10:38 PM
* To: Michael Myers; [email-masked]
* Subject: RE: SCVP-15
* 
* 
* 
* Hi Mike,
* Sorry for the slow response but I am on vacation so am not reading
mail
* as frequently as normal. I agree with your point on needing clear
* definitions for DPD and DPV but I think the ones provided in 3379 are
* adequate. That would simply require adding references to sections 2
and
* 3 of the RFC.
* 
* Do you agree?
* Trevor
* 
* * -----Original Message-----
* * From: [email-masked]
* [mailto:[email-masked]]
* * On Behalf Of Michael Myers
* * Sent: Thursday, July 22, 2004 11:43 AM
* * To: [email-masked]
* * Subject: Re: SCVP-15
* *
* *
* * Trevor,
* *
* * Section 3.2.10, extracted below, is a good step forward to closure
on
* * the issue.  Given its definition as a BOOLEAN in Query syntax, I am
* * comfortable with its default to TRUE.
* *
* * The second paragraph however needs an implementable definition of
DPD
* * vice DPV with respect to SCVP ASN.1 in order to assert that that a
* * request is in error if it asks for a validation assertion in the
* context
* * of signResponse set to FALSE.
* *
* * Mike
* *
* *
* *
* *
* * 3.2.10 signResponse
* *
* *   The signResponse specifies if the client requires the server to
* *   sign a response to the validation request. If the client is
* *   performing full chain validation on the response and it is not
* *   concerned about the authenticity of the source of the data, then
* *   the client does not benefit from the signature on the response in
* *   which case it can indicate to the server that the signature is
* *   unnecessary via the signResponse value.
* *
* *   SCVP clients that support DPD MUST support setting this value to
* *   FALSE. Since DPV responses must be signed, DPV only SCVP clients
* *   MUST NOT to support this value. SCVP servers SHOULD support
* *   returning unsigned responses. It is a local policy decision on the
* *   part of the server to return signed or unsigned responses if this
* *   value is set to FALSE.
* *
* 
* 
* 

Content-class: urn:content-classes:message
Subject: RE: Comments on SCVP15
Date: Mon, 2 Aug 2004 00:01:10 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hi Denis,
The concern you express here is touching.
See answers below.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Denis Pinkas
* Sent: Thursday, July 29, 2004 12:06 AM
* To: Peter Sylvester
* Cc: [email-masked]
* Subject: Comments on SCVP15
* 
* 
* Peter,
* 
* I am in general agreement with the *technical* comments you sent.
* 
* The current version of SCVP is still not compliant with RFC 3379.
* A large amount of work still needs to be done on this draft.
* 
* It is also a pitty that the new draft (15) has only be officially
* distributed on July 20.
* 
* On May 17, Trevor said: "I will be posting SCVP 15 shortly so you can
* review
* the latest draft." I replied: "An extract of the proposal sent to the
* mailing list and targeted to this problem would probably save another
* round."
* 
* Should I undertstand that, for Trevor, "shortly" practically means
"more
* than 2 months" ?

[TF] I will pass on you comments to my management when we are next
discussing my work schedule. I am sure they value such input.

* 
* Now awaiting SCVP-16 ... or much better, before issuing it, a response
to
* the many technical comments raised on this mailing list on SCVP-15.

[TF] A reply to you last posting has been made. What is of concern is
the fact that you requested changes in your posting on SCVP15 to
sections of SCVP which have been stable for the past 15 versions. I will
only post draft 16 when I have a definitive and final set of issues from
you and there will only be editorial changes from then on. This point is
not negotiable. Anything else will have to wait.

* 
* Denis
* 
* (as "someone participating in this list who agrees with something or
* considers it as useful").
* 
* 
* > it seems to me that some of the results of discussions between
* > the editor and me have been forgotten or so.
* >
* >
* > I still think that the scvp is not conformant to RFC 3379
* > and/or the editors has not done something as announced.
* >
* > 1) RFC 3379 says:
* >    The DPV request MUST allow the client to request that the server
* >    include in its response additional information which will allow
* >    relying parties not trusting the DPV server to be confident that
the
* >    certificate validation has correctly been performed.  Such
* >    information may (not necessarily exclusively) consist of a
* >    certification path, revocation status information from authorized
CRL
* >    issuers or authorized OCSP responders, revocation status
information
* >    from CRL issuers or OCSP responders trusted under the validation
* >    policy, time-stamp tokens from TSAs responders trusted under the
* >    validation policy, or a DPV response from a DPV server that is
* >                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[TF] Given that SCVP requires the server ensure that the validation
policy has been complied with and permits all the parameters for the
currently defined validation algorithms to be returned ( full
certificate path, CRLs, OCSP responses) then I consider SCVP to be fully
compliant with 3379. There are no currently defined validation
algorithms which have a TSA response as an input, however is such as
algorithm were to be defined, then the extension mechanisms within SCVP
would permit TSA responses to be also returned. It is also conceivable
that a validation algorithm where a DPV response from another SCVP
server was also an input, and the same extension mechanisms would permit
these responses to be likewise returned.

* >
* >    trusted under the validation policy.  When the certificate is
valid
* >    according to the validation policy, the server MUST, upon
request,
* >    include that information in the response.  However, the server
MAY
* >    omit that information when the certificate is invalid or when it
* >    cannot determine the validity.
* >
* >    ==> no provision (as far as I see).
* >
* >
* > 2) RFC 3379 says:
* >    When the DPV request is authenticated, the client SHOULD be able
to
* >    include a client identifier in the request for the DPV server to
copy
* >    into the response.  Mechanisms for matching this identifier with
the
* >    authenticated identity depends on local DPV server conditions
and/or
* >    the validation policy.  The DPV server MAY choose to blindly copy
the
* >    identifier, omit the identifier, or return an error response.

[TF]Peter had not linked our discussion on the requestor field to this
section of 3379 before. As you pointed out this field is intended for
SCVP relay so the current text is accurate for that purpose. Given that
this is a SHOULD clause you cannot claim that SCVP is non-conformant to
3379 if it does not support this feature. 

* >
* > The current text is SCVP says:
* >
* >   The OPTIONAL requestor item is used to identify the requestor.
The
* >   value is only of local significance to the requestor.  If the SCVP
* >   client includes a requestor value in the request, then the SCVP
* >   server MUST return the same value if the server is generating a
* >   specific response.
* >
* >
* > tf also said:
* >
* >
* >>Given there are plenty of ways a client can generate a "unique" as
well
* >>as other behaviors like it can encode a DN in the octet sting if it
* >>likes I don't see a problem. Its down to the client to do what it
thinks
* >>fit. The value is simply replayed by the server so it is treated a
* >>binary blob.
* >
* >
* > There is nothing else possible for the server except copying, or,
* > no mechanisms to match this with the some authenticated entity
* > can be safely developped if it is solely 'up to the client to encode
* whatever'.
* >
* > I had proposed two changes to the logic of 0 terminated octet
strings
* by:
* >
* > - a sequence of octet strings allowing a real opaque string.
* > - a choice of generalname
* >
* > I.e.
* >
* >    Identifiers ::= SEQUENCE OF {
* >           CHOICE {
* >                opaqueId OCTET STRING,
* >                nameId GeneralName
* >           }
* >
* > No comment to this proposition as far as I remember.
* >
* > 3) In May 204 trevor wrote:
* >
* >
* >>I think we can use the Cert sign bit in key usage so the is CA bit
can
* >>be removed from SCVP15
* >
* >
* > which was not done.

[TF] Yes I reconsidered that position. Since the 3280 path validation
algorithm uses the basic constrains extension as it's test for CA
certificates (3280, 6.1.4 k) and that algorithm is a mandatory feature
for every SCVP validation algorithm, I concluded it was safer to use the
same test rather than risk another based on key usage.

* >
* > 4) Somewhat related to this, and to the provisions to search in DPD
or
* validate
* >    in DPV several types of extensions, I had proposed to opetionally
* search
* >    for the pathlength basicconstraint. if for example a client has a
* >    cert and a CA cert then one could use it to search only for CAs
that
* >    have at least a pathlength of 1.
* >
* >
* > I seem to understand that the rule in this WG is:
* >
* > - editor, chairmen, iesg says something ==> accepted if no response
* > - others ==> rejected if no response from anyone.
* >
* > all totally independant of the content of the comment.
* >
* > At least point 3 doesn't fit into this rule.
* >
* > I'd like to to see whether there is someone participating
* > in this list who agrees with something or considers it as useful ...
* >
* > Thanks for consideration
* > Peter
* >
* >
* >
* >
*