Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: "David P. Kemp" <[email-masked]>
Date: Fri, 2 Jul 1999 15:43:00 -0400 (EDT)

> From: "Peter Williams" <[email-masked]>
> 
> Rather than invent a new tiny notation, perhaps just adopt the snmp
> style guidelines. A whole, multi-vendor, SNMP industry already suceeded
> in this adoption.

Agreed.

The thesis has been presented that there are device developers who
could make (compliant and secure) use of X.509 certificates if there were
a protocol to allow server-based path construction and path validation,
AND that some of those developers are so uncomfortable with ASN.1 that
they would not use SCVP unless a non-ASN.1 transfer encoding were
defined.

We have not heard from those developers on the mail list, but I am
assured that they do exist.  Perhaps casting the SCVP syntax in terms
of the ASN.1 subset defined by SNMP would reassure them that
it is indeed possible to implement SCVP on any device capable of
supporting an SNMP MIB, and that the SCVP tiny syntax is
unnecessary baggage.

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 2 Jul 1999 13:43:27 -0500

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 2:43 PM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>

Ok, providing the context was intepreted as I meant it - "rather han
invent a new tiny [ASN.1] notation [distinct from that in SNMP]...."

> supporting an SNMP MIB, and that the SCVP tiny syntax is

I think we could sensibly choose based on the communities who are being
addressed. I can see the MIB/SNMP community argument as a driver. And I
can see the type-able telnet/http/pop3 line of argument as a driver, also.

Failing some groundswell of sentiment, we will just have to let the
authors decide - unless someone can come up with some important
criteria for this tiny-msg encoding matter. There are perhaps more important
semantic issues to pursue at this first draft publication stage, along
the lines that Steven was commenting on. But, scoping out the simplicity
assumptions was useful! It is vital and represents much of the momentum
behind the draft, I suspect.

Peter.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 2 Jul 1999 14:49:58 -0700

Reasonably early on in this ASN.1/non-ASN.1 discussion, Paul had
actually put it very nicely:

> We're quite open to any syntaxes that would make client vendors more
likely
> to implement SVCP. That's precisely why we have two in the draft, and why
> all of the semantics are in a different section. If we can go with one and
> show how someone with little or no ASN.1 experience can create a program
> that writes requests and reads responses, that would be great. But I'm
> skeptical...

Neither of us is particularly tied to the syntax. We are, interested
in making sure the semantics are clear and the syntax(es) let us
express the syntax easily.

If nobody likes the tiny syntax, nobody will implement it in the
client, which will make it disappear from spec. Let's not rush in
to figure out whether there is any value to the tiny syntax. Give
it a chance and we will let developers answer that question.

*Now*, can we continue with discussing the semantic of the
protocol and whether those are useful/correct etc.?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> From: Peter Williams [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 11:43 AM
> To: David P. Kemp; [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 05 Jul 1999 10:39:31 +0200

Ambarish wrote:

[text deleted]

> protocol and whether those are useful/correct etc.?

Here are a few comments on the SCVP document.

1. I was expecting (and still I am !) the document to address the problem: "Was
that certificate valid at that time ?" However, currently it does not, because
there is no indication of date, such as ValidAt in the request so only the
current date can be used.

2. Validation can only occur according to strict rules. Two parameters may be
used to achieve this: TrustedRoots and UsageID. In the text (sections 3.14 and
3.15) there is no indication to know which is mandatory or optional. When
looking at the ASN1 both are OPTIONAL without any additional information. I
would think that one of them shall be present. Is this interpretation correct ?
However, it should be realized that using the TrustedRoots parameter makes a
"loose" validation that does not take into consideration policy constraints and
naming constraints at every node of the certification chain. The use of UsageID,
which should be renamed something like ValidationPolicy to better describe what
it is, allows more complex cases of validation. This also means that the
TypeOfCheck parameter (with the value zero) does not bear the right meaning: the
check is not necessarily a validation to a trusted root, but also a validation
according to a validation policy.

3. An individual Certificate to be validated may be accompanied not only with a
sequence of certificates (IntermediateCerts) but also by a sequence of
revocation information (CRLs and/or OCSP responses) that the (thin) client got
by some way, but is unable or unwilling to validate itself. A parameter like
RevocationInformation should be added.

4. The WantBack parameter allows to get back (item 2) "the certificate chain
used to validate the certificate". This is not sufficient. As another option it
should be possible to get back the RevocationInformation mentioned earlier so
that the client can get back not only the sequence of certificates but also a
sequence of revocation information (CRLs and/or OCSP responses).

Minor comments:

5. The TrustedRoots contained in the CertBundle are defined as a FullCert or a
CertID. In reality this is a self signed certificate. I have difficulties to
understand how it can be only a hash, without further information.

6. The IntermediateCerts contained in CertBundle may contains the FullCert or
the CertID. I have difficulties to understand why the CertID is only the hash of
the certificate and not the CA name + serial number + optionally the hash of the
certificate under query. If the hash of the Certificate under query is not
given, then it shall be returned in the response.

Finally :

7.One question is whether the problem that is attempted to be addressed should
be solved by an extension to OSCP, DCS or SCVP (i.e. this new document). There
has been very little discussion on DCS and a new version of that document has
been made available past the dead line (I have not looked at it). I will not
answer the question, but surely this is a matter for consideration.

8. Following the discussion about the tiny syntax, the fact that SNACC can be
used, seems to make the tiny syntax unnecessary. The use/definition of a reduced
set of ASN1 might be the solution.

Denis