Subject: Re: SCEP newest spec

From: "Al Arsenault" <[email-masked]>
Date: Mon, 23 Jun 2003 15:16:07 -0400

>
>
> > All IETF WGs have (or should have) as a goal not creating duplicative
> > standards.
>
> In which case the IETF PKIX group will kindly stop work on SCVP which
> duplicates functionality of the XKMS specification which has already
> passed last call.
>

AWA:  Gee, I can't find any references to XKMS having been submitted for
IETF last call.  It's not in the queue.  Can you provide a pointer to the
action?

When I "SWFG" (to use your acronym) on IETF & XKMS I got a bunch of
references to SACRED work, a document in the TRADE group, and a bunch of
stuff about "W3C XKMS" meetings in conjunction with IETF meetings.

What?  Oh, you mean that XKMS hasn't been through an IETF last call; it's
some other standards group (specifically, W3C)?  Ah, yes, then, IETF should
clearly bow out of this area and accept what W3C has done as "gospel truth".
Nahhh!

If IETF is going to get into the mode of simply accepting what somebody else
has done, even if we regard it as not correct or not applicable or applying
to a different context or ..., then we're going to get into trouble quickly.
For example, should we accept/endorse X9.68 certificates?  Why not? What
about WTLS?  etc., ad infinitum, ad nauseum

>
> The way the IETF used to work was by recognizing de-facto standards
> that had achieved acceptance.
>

AWA:  In general, I find that approach more palatable than "here's the
answer a priori from us experts on high, before the technology has even been
developed".  With caveats, of course - just because it has achieved
acceptance doesn't mean it's free from major security problems.

And the fact that a company that styles itself as the leader in a particular
area has done something doesn't mean that everybody else must do it as well.

WRT XKMS:  it has achieved some measure of acceptance in IETF (the SACRED
working group, among others).  That's fine.  But that doesn't mean that XKMS
is the single solution that will be used, or even that it is  the best
solution to solve a specific problem.

> > By all means, feel free to bring SCEP to OASIS, a standards body
> > where architectural concerns do not seem to interfere with the
> > promotion of vendor protocols.
>
> I used to believe all that stuff about architecture, but no longer.
>
> IETF is hierarchy for the sake of hierarchy. The real reason they created
> the IAB, IESG etc. was to keep control out of the wrong hands which
> empirically would appear to be anyone who is willing to submit to its
closed
> process with no accountability.
>
> The IETF stopped working as soon as it broke the rule of 150.
>
> Phill

AWA:  The IETF clearly has a lot of problems, many of which are brought
about because (a) the size has gotten so large that most
attendees/participants don't actually provide anything useful; they're just
their to report back on what's happening; (b) certain personalities seem to
be in the way of what others would consider progress (sometimes that's good,
sometimes bad; it depends on what you consider "progress"); (c) the market
is so large and the competing interests so powerful that it's hard to
overcome the inertia and get everybody to actually make a change; (d)
probably other reasons as well.

On the other hand, given some of the other standards and industry groups in
which I've worked, IETF often looks really good.

                Al Arsenault

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 23 Jun 2003 22:39:34 +0200

Al Arsenault wrote:
[ ... ]
> area has done something doesn't mean that everybody else must do it as well.

[ ... ]

I have been working on the SCEP and really I find there are some flaws and
some things could have been done in a better way. Anyway there is a de
facto "quasi" standard and my position is that ietf should try to address
the problem.

I am just addressing the issue from a practical point of view, I guess that if
we can take over the SCEP protocol and make it a standard - improving what
should be improved - a wider and wiser discussion can be made and from which the
whole community will be having benefits.

Also, new versions of the protocol could be made stronger and somehow not
colliding to other existing IETF standards.

Just think about the possibility (and this is referred to the whole list) and
if enough people agree we could start some work, otherwise we close the thread
once for all.

IMHO we should address the issue.

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                [email-masked]
                                                  Tel.:   +39 (0)59  270  094
http://www.openca.org                            Fax:    +39   178  221 8225
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 23 Jun 2003 10:47:14 -0700

IETF is hierarchy for the sake of hierarchy. The real reason they created
the IAB, IESG etc. was to keep control out of the wrong hands which
empirically would appear to be anyone who is willing to submit to its closed
process with no accountability.

		Phill

---

From: Max Pritikin <[email-masked]>
Date: Mon, 23 Jun 2003 22:41:47 -0700 (PDT)

Massimiliano,

For specific questions and concerns about SCEP you could send mail to:
	[email-masked]
I assure you your comments will be appreciated.

I really wish there was only one enrollment protocol. From my perspective
the current stalemate has done more to harm public key infrastructure
deployment than anything else.

So, is there any way for PKIX to settle on a single enrollment protocol?

	- max

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jun 2003 07:32:58 -0700

I can buy into that this is particular to XKMS or SCEP as an effort as a
thread here in PKIX because PKIX has particular need to be able to be
interoperable in the Security and Information Assurance space. But at the
bigger-picture view, it seems to me that this is turning into a POISED/IPR
issue about how to induct external works for formal reference in IETF
efforts, because that is clearly from this and other conversations one of
the IP management issues that this governance team needs to address, and
soon I would say.

Todd

----- Original Message ----- 
From: "Al Arsenault" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>; "'Stephen Kent'"
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 23, 2003 12:16 PM
Subject: Re: SCEP newest spec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jun 2003 22:07:41 -0400

>The IETF stopped working as soon as it broke the rule of 150.

Phill,

Is this an April fool's message that was delayed?

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 25 Jun 2003 09:44:10 +0200

Phill,

>> duplicates functionality of the XKMS specification which has already

Following a request made to the PKIX WG on May 7, I sent 35 comments on XKMS 
Version 2 (April 18, 2003) to the editor - [email-masked] and cc: 
[email-masked]. The Last Call review period ended on 23 May, 2003.

I am quite surprised you say that the XKMS specification has already passed 
last call, since my 35 comments have never been discussed with me, nor answered.

Hereafter is again a copy of my comments (note sure that this message will 
go to the list, since it might be too long):

Comments on XKMS Version 2 (April 18, 2003)

The model has severe limitations which are not mentioned in the document.

1. The overall model is making the silent assumption that only names that 
are unique by their structure, i.e. DNS names, RFC 822 names or IP 
addresses, shall be used. Since DNS names, RFC 822 names and IP addresses 
are unique, there is no difference between such names certified by CA1 or 
CA2. If Distinguished Names (DNs) were being used, a DN certified by CA1 and 
the same DN certified by CA2 could correspond to the same or to different 
entities. XKMS currently prohibits the use of DNs or, said in other words, 
exhibits security problems if such names were being used. This should be 
clearly advertised, or a fix to this problem should be made.

2. A major error in XKMS is to consider to obtain information about keys, 
rather than information against certificates, which bind a public key to a 
name for a specific key usage and under a Certification Policy. Since there 
is not a one-to-one relationship between a key and a certificate, but a 
one-to-many relationship, it is not possible to make an unambiguous binding 
with a public key but only an unambiguous binding with a (public key) 
certificate.

3. The Certification Policy is a concept which seems to be ignored at the 
level of the interfaces that are being proposed.

4. In section [46] the text says:

"The XKMS specification defines three types of request:

X-KRSS Request
      A Register, Reissue, Revoke or Recover request as specified by the Key 
Information Service Specification".

There is indeed a typo, probably intentionally left by the editor, to make 
sure that at least someone read the specification: "Key Information Service 
Specification" should be changed into "Key *Registration* Service 
Specification".

5. The <ds:KeyInfo> (see [135]) is described as an "hint". This should not 
be the case since it is important to make sure under which certificate a 
signer wanted to sign. Several certificates may include the same public key 
and for that reason it is important to make sure that the certificate (or an 
unambiguous reference to it) is linked to the data that has been signed and 
is indeed protected by the signature. Without that link certificates could 
be substituted without notice. The concept is similar to ESSCertID that is 
used in CMS (see RFC 2634).

6. The fact that ds:KeyInfo> may or may not be cryptographically bound to 
the signature itself is advertised as an important property (see [136]). It 
is said: "This allows the <ds:KeyInfo> to be substituted or supplemented 
without "breaking" the digital signature". This should be considered as a 
severe weakness, since such a substitution is not desirable (see above). A 
certificate could be added, but the reference to the certificate should 
remain unchanged and unchangeable.

7. The XKISS Validate service verifies a binding with a public key, while 
the binding should be verified with a certificate (which contains a public 
key), instead of directly a public key value. CAs may deliver different 
certificates with the same public key but with different attributes in them. 
It is important to know which certificate has been used, rather than which 
public key has been used, since several certificates may include the same 
public key.

8. The two overviews from sections 1.5 and 1.6 do not provide a clear 
picture of the functions that are supported. They should be both revised. A 
text is proposed as an annex at the end of these comments.

9. The document provides several examples which are quite interesting. 
However the core of a standard should not include examples. Such examples 
should be placed in an annex. However if these examples were removed the 
text would not be understandable anymore, because the remaining explanations 
would be insufficient. It is thus requested to add more normative text and 
to move the examples in an informative annex.

10. The XKISS Locate service is defined as " The XKISS Locate service 
resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an 
assertion concerning the validity of the binding between the data in the 
<ds:Keyinfo> element". What means "resolving <ds:Keyinfo> element" is not 
self-understandable. The exact processing that is supposed to be done by the 
service should be described in details.

11. The example (see [145]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.

The service seems to return only a key value, while it should return the 
main components from a certificate.

 From the example, it can be seen that the input parameters are a DNS name 
and the name of a protocol. Since no key usage is mentioned, the service is 
unable to know whether a certificate that includes a signature verification 
key or includes an encryption key is requested. A certificate should be 
returned and not a key, so that the user can verify the validity period of 
the certificate, otherwise a validity date should be included in the 
request. The certification policy contained in the certificate may also be 
helpful, unless it is specified in the request.

12. The XKISS Validate service is defined as : "The XKISS Validate Service 
allows all that the Locate Service does, and in addition, the client may 
obtain an assertion specifying the status of the binding between the public 
key and other data, for example a name or a set of extended attributes". 
What means "other data" is not self-understandable. The exact processing 
that is supposed to be done by the service should be described in details.

13. In [152] it is mentioned: "Furthermore the service represents that the 
status of each of the data elements returned is valid and that all are bound 
to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Data> 
element. Therefore the binding is not with a key but with a certificate.

14. The example (see [155]) is insufficient to describe what that service 
really does. The various input (and output) parameters should be clearly 
described. This is not the case.
In particular, is the validation done only for the current time or can it be 
done for a time in the past ? Even, if this is the current time, is that 
time indicated in the response? The answer is only given (hidden) in section 
[215], but this should be clearly advertised upfront.

15. From its name, the XKISS Validate Service present a few similarities 
with the validation service requirements that have been defined by the PKIX 
WG from the IETF. This working group has produced RFC 3379 (Delegated Path 
Validation and Delegated Path Discovery Protocol Requirements) which is a 
set of requirements.

However, the XKMS specification is leaving aside many, if not most, of the 
these requirements. An important concept from RFC3379 is the concept of 
"validation policy". When a validation is done, it must be done according to 
a set of rules. These rules depends upon the application. In particular some 
root keys may be adequate for an application, but not for another. Trust 
elements cannot be uniform and cannot be left open to the Validate Server.

The text is speaking of a "validation criteria (see [161]), but it is 
unclear what it really is. This is one of the most severe limitations of 
XKMS and this limitation is not advertised.

It would be quite interesting to understand why the requirements from 
RFC3379 have not been followed.

16. The text is speaking of some means to locate the correct XKMS service 
(see [163]) but does not provide any guidance in order to solve this 
problem, in particular in the context of multiple servers offering their 
services to the users.

17. The text in [168] states: "the Service represents to the client 
accessing the service and to that client alone that the binding between the 
data elements is valid under whatever trust policy the service offers to 
that client." Unless the service can clearly advertise which trust policy is 
being used, the client cannot use any kind of trust policy without even 
knowing which one it is. As already stated, the concept of validation policy 
is not supported, but should be supported.

18. The text under [171] mentions: "The Id identifier is defined to provide 
a means by which the key binding may be signed using XML Signature. Clients 
MUST NOT rely on the key binding identifier being either unique or stable". 
On the contrary it is believed that a key identifier should be unique. The 
ESSCertID from RFC 2634 is a good example of such a unique binding.

19. The text under [174] considers only three intended uses of the key:

   1) Encryption : The key pair may be used for encryption and decryption,
   2) Signature : The key pair may be used for signature and verification,
   3) Exchange: The key pair may be used for key exchange.

However, the key usages should be defined in terms of security services (see 
ISO 7498-2), i.e. authentication service, confidentiality service and 
non-repudiation service.

To avoid some security problems it is particularly important to make a 
difference between a key usable for authentication and a key usable for 
non-repudiation. This cannot be covered by a single key usage called 
"signature".

20. The text under [177] mentions the <UseKeyWith> element which specifies a 
subject identifier and application identifier that determine a use of the 
key. The <UseKeyWith> must contain "Application" which is a URI that 
specifies the application protocol with which the key may be used and 
"Identifier" which specifies the subject to which the key corresponds within 
the specified application protocol. A protocol can support a sender and a 
receiver. It is unclear whether the Identifier corresponds to the sender or 
the receiver. It seems that the notion is by itself insufficient and should 
be extended to make such difference.

21. The text under [180] mentions S/MIME as a protocol. Why is CMS 
(Cryptographic Message Syntax) not considered as a protocol as well ?

22. The text under [180] mentions PKIX. It is very unclear to understand why 
PKIX is considered as a "protocol" since it is only a set of data structures.

23. The text under [180] mentions the use of "Certificate Subject Name" as 
an appropriate identifier. It should be observed that this name only is 
insufficient to correctly identify an entity, since two CAs may certify the 
same name and that this name may correspond to the same or to different 
entities. Unless a sequence of CAs names is added to the entity name up to a 
root key, such names are ambiguous. This relates to the non-uniqueness of DN 
names already mentioned.

24. The text under [180] identifies various protocols. To this list, XAdES 
(XML Advanced Electronic Signature) which is a W3C Note issued on February 
20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The 
"identifier" type is such a case is a SigningCertificate element, i.e. *not* 
a DN.

25. The description of the Validate Service are confusing. It seems to 
relate more to the Locate Service rather than the Validate Service where the 
primary response should be "valid according to some policy" or "invalid 
according to some trust policy". The exact service performed by the Validate 
Service is not sufficiently detailed.

26. In [221] it is mentioned: "The server returns one or more <KeyBinding> 
elements that meet the criteria specified in the request." It is 
questionable why not simply a valid, invalid or don't know assertion is made 
against the proposed binding.

27. In the case of validation, the "yet not valid" response should be 
considered, in particular when a certificate is suspended. This means that 
another validation request made later on may succeed.

28. The Register Service from KRSS is not sufficiently described. The two 
examples provide more information, but that information is not normative. 
 From the example, two features are mentioned:

1° authentication information to be used later on for revocation can be 
transmitted. However, it is unfortunate that the data does not also include 
the question to be answered.

2° it is necessary to have a face to face contact with the LRA before being 
able to use the register request. During that face to face information is 
captured by the LRA and the secret "authentication code" is provide to the 
end-user. However, this method is time consuming and does not allow a cost 
effective deployment of a PKI.

It is suggested to use another technique that places all the burden of the 
typing for the end-user, who receives back both a registration number and 
the hash of his request (signed by the service) so that the end-user can 
then authenticate to the LRA in a face to face where the Register Service 
has only to verify the information (and to only "click" to accept or 
reject). Another advantage is that no secret information is being used.

29. In the example [241] several identifiers are included :

<UseKeyWith Application="urn:ietf:rfc:2459"
Identifier="C=&quot;US&quot; O=&quot;Alice Corp&quot;
CN=&quot;Alice Aardvark&quot;"/>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="[email-masked]"/>
<UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
Identifier="[email-masked]"/>

It is unclear to understand how the concept of "UseKeyWith Application" will 
be translated in an X.509 certificate, since an X.509 certificate does not 
support the concept of "UseKeyWith Application".

30. In the example [245] the private key is returned in the response. It 
will be quite uneasy for the end-user to memorize the authentication code 
3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some 
out-of-band mechanism. This method would be quite difficult to use and would 
not allow an easy and cost effective deployment of a PKI. It is suggested to 
use another technique that allows the end user to locally generate a key 
pair, so that the public key can be sent in the Register Service request and 
then used by the Register Service to encrypt the private key once generated. 
The main advantage is that no secret information is being used and no 
out-of-bands mechanism is necessary.

31. The Reissue request mentions "A reissue request is made in the same 
manner as the initial registration of a key". It is not believed that this 
statement is correct. The user should provide the previously obtained 
certificate and ask for another validity period. There is no need to specify 
again secret information obtained through an out of bands mechanism.

32. The Revocation request should allow the possibility to carry a reason 
code and an Invalidity Date (RFC 2459 sates that CRL issuers are strongly 
encouraged to include meaningful reason codes in CRL entries).

33. The Revocation request example includes the certificate. It is very 
doubtful that the user will be able to provide its full certificate, if his 
smart card has been stolen. However he could more easily provide his subject 
name instead. The input and the output parameters are not sufficiently 
described.

34. The Recovery request mentions "A key recovery request is made in the 
same manner as the initial registration of a key". It is not believed that 
this statement is correct. There is no need to specify again secret 
information obtained through an out of bands mechanism.
Users do not have only a confidentiality key, but also an authentication 
key. They could use it to authenticate. If they loose everything, they could 
encrypt the authentication code under a key they wish their private key to 
be recovered (using PKCS#12) and authenticate their request by phone using 
the non-secret registration number of their request. For this to be 
possible, a hash of the request should be present in the response.

35. The security considerations section should be augmented to mention the 
severe limitations that are indicated above.

ANNEX

The following text is proposed as a global overview of these two sections.

Note: This text is re-using text already present and does not include 
changes that are suggested in the other comments.

"The XKMS specification defines three types of requests:

1. X-KISS (Key Information Service Specification) Request : A Locate or a 
Validate request.

The XKISS Locate service provides one or more unverified key bindings to the 
best of its knowledge but does not provide any assurance about that binding. 
Information obtained from a Locate service SHOULD NOT be relied upon unless 
it is validated. Validation may be achieved by forwarding the data to a 
Validate service or by performing the necessary trust path verification locally.

The XKISS Validate service allows a client to query the binding between a 
<ds:Keyinfo> element (i.e. <ds:X509Data>, <ds:X509Data>*, <ds:KeyName>, 
<ds:KeyValue>) and one or more <UseKeyWith> elements (i.e. an application 
protocol with which the key may be used and an "identifier" which specifies 
the subject to which the key corresponds within the specified application 
protocol).

2. X-KRSS (Key Registration Service Specification) Request :The XML Key 
Registration Service Specification permits management of information that is 
bound to a public key pair. The XKRSS service specification supports the 
following operations:

a)  Register : The Registration request message contains a prototype of the 
requested key binding which may contain only partial information, a key 
without a name or a name without a key. The registration service MAY require 
the client to provide additional information to authenticate the request. If 
the public key pair is generated by the client, the service MAY require the 
client to provide Proof of Possession of the private key.

b)  Reissue : A previously registered key binding is reissued unchanged 
except the validity period.

c)  Revoke : A previously registered key binding is revoked.

d)  Recover : The private key associated with a key binding is recovered.

3. Compound Request : A compound request allows multiple X-KISS or X-KRSS 
requests and the corresponding responses to be sent in a single message. 
This allows considerable processing resources to be saved as a single 
signature on the compound message may be used in place of multiple 
signatures on the individual requests or responses.

Denis